Создание игрового сайта в Интернете
Проектирование и реализация информационной системы по поддержке игрового сайта в Интернете. Создание и разработка базы данных для хранения информации на основе требований заказчика и программного обеспечения для обработки данных: структура и дизайн сайта.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 21.11.2010 |
| Размер файла | 602,5 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Game(GameId, SymbolName, Genre, Developer, Publisher, PublishYear, SystemMin, SystemMax, Multiplayer, AmountCD)
Primary Key GameId
Alternate Key SymbolName
GameId -> SymbolName, Genre, Developer, Publisher, PublishYear, SystemMin, SystemMax, Multiplayer, AmountCD
SymbolName -> GameId, Genre, Developer, Publisher, PublishYear, SystemMin, SystemMax, Multiplayer, AmountCD
Authors(AuthorId, Name, Nick)
Primary Key AuthorId
Alternate Key Nick
AuthorId -> Name, Nick
Nick -> AuthorId, Name
Archive(Num, Year, Month)
Primary Key Num
Alternate Key Year, Month
Num -> Year, Month
Year, Month -> Num
GameRubric(GrubricId, GRubric)
Primary Key GrubricID
Alternate Key Grubric
GrubricID -> Grubric
Grubric -> GrubricID
JournalRubric(JrubricId, JRubric)
Primary Key JrubricId
Alternate Key Jrubric
JrubricId -> Jrubric
Jrubric -> JrubricId
Demoversions(NameId, GameId, Size, Links, Comment, UploadTime)
Primary Key NameId
Alternate Key Links
NameId -> GameId, Size, Links, Comment, UploadTime
Links -> NameId, GameId, Size, Comment, UploadTime
Trainers(NameId, GameId, Version, Comment, FileName, UploadTime)
Primary Key NameId
Alternate Key FileName
NameId -> GameId, Version, Comment, FileName, UploadTime
FileName -> NameId, GameId, Version, Comment, UploadTime
Patches(NameId, GameId, Version, Comment, PublishTime, UploadTime, Links)
Primary Key NameId
Alternate Key Links
NameId -> GameId, Version, Comment, PublishTime, UploadTime, Links
Links -> NameId, GameId, Version, Comment, PublishTime, UploadTime
Wallpapers(NameId, GameId, UploadTime, PicDir)
Primary Key NameId
Alternate Key PicDir
NameId -> GameId, UploadTime, PicDir
PicDir -> NameId, GameId, UploadTime
Videorollicks(NameId, GameId, Size, Links, Comment, UploadTime)
Primary Key NameId
Alternate Key Links
NameId -> GameId, Size, Links, Comment, UploadTime
Links -> NameId, GameId, Size, Comment, UploadTime
GameArticle(NameId, GameId, Num, GrubricId, PubPlace)
Primary Key NameId
Alternate Key GameId, Num, GrubricId, PubPlace
NameId -> GameId, Num, GrubricId, PubPlace
GameId, Num, GrubricId, PubPlace -> NameId
NonGameArticle(NameId, Num, JrubricId, ArtName)
Primary Key NameId
Alternate Key Num, JrubricId, ArtName
NameId -> Num, JrubricId, ArtName
Num, JrubricId, ArtName -> NameId
Writing(GameId, NameId)
Primary Key NgameId, NameId
Work_GA(AuthorId,GameId)
Primary Key AuthorId, NameId
Work_NGA(AuthorId,NameId)
Primary Key AuthorId, NameId
В приведенной модели все отношения не содержат повторяющихся групп атрибутов, частично или транзитивно зависящих от первичных ключей этих отношений. Более того, каждый детерминант любого отношения является первичным или потенциальным ключом этого отношения.
В результате можно сделать вывод, что все отношения находятся в НФБК.
Этап 2.4 Проверка модели в отношении транзакций пользователей
Назначение этого этапа состоит в проверке локальной логической модели данных в отношении возможности выполнения всех транзакции, предусмотренных спецификациями. Для этой цели мы используем ER-диаграмму, а так же прилагаемую к ней документацию. Исходя из этих данных, мы предпримем попытку выполнить каждую из транзакций вручную. Если это окажется возможным для всех транзакций, то можно считать, что данная логическая модель успешно проверена. Если же выполнить вручную некоторую из транзакций окажется невозможным, значит, в логической модели данных присутствует ошибка, которую следует устранить. Вероятнее всего, в модели отсутствует необходимая сущность, связь или атрибут. В то же время, если некоторая часть логической модели окажется излишней для выполнения всего набора требуемых транзакций, даже с учетом возможности его расширения в будущем, есть все основания полагать, что эта часть модели является избыточной и подлежит удалению из окончательного варианта логической модели данных представления.
Существует два возможных подхода к проверке логической модели данных в отношении возможности выполнения всех транзакций, указанных в спецификациях.
Первый подход заключается в том, что бы проверить, вся ли необходимая для выполнения каждой транзакции информация может быть получена в данной модели. Проверка осуществляется с помощью описания процедуры выполнения транзакции.
Второй подход к проверке возможности выполнения транзакций связан с графическим представлением метода выполнения каждой из транзакций на диаграмме локальной логической модели данных. Остановимся на рассмотрении второго варианта, как наиболее наглядного.
На представленной на рисунке ER-4 модели показаны пути выполнения всех перечисленных в спецификациях транзакций. Путь выполнения каждой транзакции показан в виде линии со стрелкой, указывающей направление выполнения транзакции и соединяющей сущности, а также связи, необходимые для её выполнения. Каждая линия обозначена символами T(x), где х - номер транзакции в списке (см. пункт 1.1.2 «Концептуальное проектирование»).
Этап 2.5 Создание диаграммы «сущность-связь»
В ходе последних этапов не возникло необходимости вносить изменения в диаграмму, изображенную на рисунке ER-3. Поэтому она волне подойдет в качестве окончательного варианта ER диаграммы.
Физическое проектирование.
Разработка физического проекта базы данных.
На этом этапе будет проведено физическое проектирование базы данных на основе построенной на предыдущем этапе логической модели данных.
Этап 3. Перенос глобальной логической модели данных в среду целевой СУБД.
Основной целью этого этапа является создание базовой функциональной схемы реляционной базы данных на основе глобальной логической модели данных.
На этом этапе мы преобразуем глобальную логическую модель данных в такую форму, которая позволит реализовать данный проект в среде выбранной елевой реляционной СУБД, а именно в среде СУБД MySQL.
Этап 3.1 Проектирование таблиц базы данных в среде целевой СУБД
На основе полученных, на этапе логического проектирования данных, можно приступать к непосредственному созданию базы данных и таблиц в ней.
Создание базы данных.
Создание базы данных - очень простая операция. Для её выполнения достаточно ввести оператор CREATE DATABASE имя_базы. Базу я назову igromania. Сразу после её создания я объявляю эту базу данных как текущую. Эта операция совсем не обязательна, так как к базе данных можно обращаться в формате db_name.tbl_name. Но очевидно, что удобнее ссылаться на таблицы, не прибегая при этом к помощи полного квалификатора. Таким образом, зайдя в интерфейс администрирования MySQL, просто набираем:
mysql> CREATE DATABASE igromania;
mysql> USE igromania;
Теперь база готова к следующему этапу - созданию таблиц.
Создание таблиц.
СУБД MySQL позволяет создавать и удалять таблицы, модифицировать их структуру с помощью традиционных SQL операторов CREATE TABLE, DROP TABLE и ALTER TABLE. Каждый из этих операторов имеет дополнения, сделанные для диалекта языка SQL, принятого в СУБД MySQL. Это было сделано для повышения их эффективности.
СУБД MySQL 3.23 позволяет создавать таблицы с использованием трех форматов представления данных: MyISAM, ISAM, HEAP. [6]
§ Таблицы ISAM. Это самый старый метод хранения таблиц в памяти, принятый за стандарт для версий, меньше 3.23. Используется до сих пор. Но в целом лучше пользоваться новым форматом MyISAM, так как он накладывает меньше ограничений.
§ Таблицы MyISAM. Этот формат хранения таблиц в памяти, впервые появившийся в версии 3.23, является форматом хранения по умолчанию.
· Файлы могут иметь длину большую, чем при использовании метода ISAM.
· Данные хранятся в машинно-независимом коде с первым младшим байтом впереди. Такой формат позволяет копирование с одного компьютера на другой, даже, если их архитектуры различны.
· Значения индексов требуют меньше памяти, так как они хранятся с первым старшим байтом. Индексы имеют тенденцию к частому изменению, поэтому старшие байты можно безболезненно подвергать сжатию.
· Обработка параметра AUTO_INCREMENT более эффективна, чем при использовании формата ISAM.
· Снято несколько ограничений, налагаемых на индексируемые столбцы. Такие столбцы могут содержать пустые значения (NULL), появилась возможность индексировать столбцы типа BLOB и TEXT.
§ Таблицы HEAP. Этот метод хранит таблицы прямо в оперативной памяти, что значительно ускоряет работу с таблицами. При этом таблицы должны иметь строки фиксированной длины.
Создание таблиц осуществляется оператором CREATE TABLE. Ниже приведены команды для создания таблиц. Имена таблиц в большей степени соответствуют именам соответствующих отношений из логической модели данных. Итак, приступим:
CREATE TABLE Archive (
Num int(11) NOT NULL default '0',
Year int(11) NOT NULL default '0',
Month int(11) NOT NULL default '0'
) TYPE=MyISAM;
CREATE TABLE authors (
AuthorId int(11) NOT NULL auto_increment,
Name varchar(255) NOT NULL default '',
Nick varchar(255) NOT NULL default '',
PRIMARY KEY (AuthorId)
) TYPE=MyISAM;
Здесь поле AuthorId объявлено, как PRIMARY KEY со свойством auto_increment. Это означает, что с каждым добавлением новой строки значение этого поля будет уникальным и назначаться автоматически в порядке возрастания, начиная с нуля.
Таблица GamesNames будет хранить информацию по играм. Она будет описывать отношение Game из логической структуры.
CREATE TABLE GamesNames (
GameId varchar(255) NOT NULL default '',
Litera varchar(3) NOT NULL default '',
SymbolName varchar(255) NOT NULL default '',
Developer varchar(255) default NULL,
Publisher varchar(255) default NULL,
Genre varchar(255) default NULL,
PublishYear varchar(255) default NULL,
SystemMin varchar(255) default NULL,
SystemMax varchar(255) default NULL,
Multipleer varchar(255) default NULL,
AmountCD varchar(255) default NULL,
UNIQUE KEY GameId (GameId),
UNIQUE KEY SymbolName (SymbolName),
KEY Litera (Litera)
) TYPE=MyISAM;
Здесь дополнительно введены еще 2 поля - Litera и PrimaryDir. Для сортировки названий игр по алфавиту возникла необходимость в определении поля Litera, значениями которого могут быть или любая буква латинского алфавита, или значение «RUS», или символ «#».
CREATE TABLE rubrics (
GRubricId int(11) NOT NULL auto_increment,
GRubric varchar(255) NOT NULL,
KEY GRubricId (GRubricId)
) TYPE=MyISAM;
Эта таблица описывает отношение GameRubric
CREATE TABLE artrubrics (
JRubricId int(11) NOT NULL auto_increment,
JRubric varchar(255) NOT NULL,
KEY JRubricId (JRubricId)
) TYPE=MyISAM;
Эта таблица описывает отношение JournalRubric
CREATE TABLE Demoversions (
NameId int(10) NOT NULL auto_increment,
GameId char(255) NOT NULL,
Size char(255),
Link1 char(255),
Link2 char(255),
Link3 char(255),
Link4 char(255),
Link5 char(255),
Link6 char(255),
Link7 char(255),
Link8 char(255),
Link9 char(255),
Link10 char(255),
UploadTime timestamp(14),
KEY UploadTime (UploadTime),
KEY NameId (NameId)
) TYPE=MyISAM;
Создан индекс по полю UploadTime. Сделано это для ускорения сортировки по этому полю.
CREATE TABLE trainers (
NameId int(10) unsigned NOT NULL auto_increment,
GameId varchar(255) NOT NULL,
FileName varchar(255) NOT NULL,
Version varchar(255),
UploadTime int(11),
Comment text,
KEY NameId (NameId),
KEY UploadTime (UploadTime));
CREATE TABLE patches (
NameId int(10) unsigned NOT NULL auto_increment,
GameId varchar(255) NOT NULL,
Version varchar(255),
PublishTime varchar(255),
UploadTime int(11),
Comment text,
Link1 varchar(255),
Link2 varchar(255),
Link3 varchar(255),
Link4 varchar(255),
Link5 varchar(255),
Link6 varchar(255),
Link7 varchar(255),
Link8 varchar(255),
Link9 varchar(255),
Link10 varchar(255),
KEY NameId (NameId),
KEY UploadTime (UploadTime));
CREATE TABLE wallpapers (
NameId int(10) unsigned NOT NULL auto_increment,
GameId varchar(255) NOT NULL,
UploadTime int(14),
KEY NameId (NameId),
KEY UploadTime (UploadTime));
Еще одно поле PicDir, определяющее имя каталога, решено было удалить из рассмотрения. Это связано с тем, что в имя каталога будет идентичным значению поля GameId.
CREATE TABLE videorolicks (
NameId int(10) NOT NULL auto_increment,
GameId char(255) NOT NULL,
AmountIndex int(11) DEFAULT '1' NOT NULL,
Time char(255),
Size char(255),
pic1_min char(255),
pic1_max char(255),
pic2_min char(255),
pic2_max char(255),
Link1 char(255),
Link2 char(255),
Link3 char(255),
Link4 char(255),
Link5 char(255),
Link6 char(255),
Link7 char(255),
Link8 char(255),
Link9 char(255),
Link10 char(255),
UploadTime int(11),
KEY NameId (NameId),
KEY UploadTime (UploadTime));
CREATE TABLE games (
NameId int(10) NOT NULL auto_increment
GameId varchar(255) NOT NULL,
GRubricId varchar(255) NOT NULL,
PubPlace int(11) DEFAULT '0' NOT NULL,
UploadTime int(14),
Num varchar(255) DEFAULT '0' NOT NULL,
KEY UploadTime (UploadTime));
Эта таблица описывает отношение GameArticle.
CREATE TABLE articles (
NameId int(10) NOT NULL auto_increment
JRubricId varchar(255) NOT NULL,
ArtName varchar(255) NOT NULL,
Num varchar(255) NOT NULL,
UploadTime int(11) DEFAULT '0' NOT NULL,
KEY UploadTime (UploadTime));
Эта таблица описывает отношение NonGameArticle.
CREATE TABLE articles_games (
NameId int(10) NOT NULL,
GameId varchar(255) NOT NULL,);
Эта таблица описывает отношение Writing.
CREATE TABLE game_author (
AuthorId int(11) DEFAULT '0' NOT NULL,
GameId varchar(255) NOT NULL);
Эта таблица описывает отношение Work_GA.
CREATE TABLE art_author (
AuthorId int(11) DEFAULT '0' NOT NULL,
NameId int(11) DEFAULT '0' NOT NULL);
Эта таблица описывает отношение Work_NGA.
Этап 4. Разработка механизмов защиты
База данных представляет собой один из важнейших корпоративных ресурсов, поэтому защита этого ресурса является чрезвычайно важной задачей. Под защитой базы данных понимается обеспечение защищенности базы данных против любых предумышленных или непредумышленных угроз с помощью различных компьютерных и некомпьютерных средств.
Выделяют несколько основных методов защиты информации в базах данных [1]. Ниже описаны эти методы и степень реализации их в конкретном случае.
1) Резервное копирование. Разработан программный модуль, который ежедневно, в ночное время (в период минимальной нагрузки на сервер) осуществляет резервное копирование на диск всей информации, хранящейся в базе данных. И ежемесячно осуществляется полное копирование и сохранение всей информации на сайте, в том числе и базы данных.
2) Авторизация и аутентификация. Разработан механизм авторизации администраторов данных. Доступ к программным модулям, с помощью которых осуществляется внесение, изменение, удаление информации в базу данных, осуществляется после предварительной авторизации.
3) Поддержка целостности данных. Поддержка целостности данных осуществляется соблюдением двух правил целостности, которые, по сути, являются ограничениями на все допустимые состояния базы данных.
Первое правило - это целостность сущностей. Смысл этого правила заключается в том, что в базовом отношении ни один атрибут первичного ключа не может содержать отсутствующих значений, обозначаемых определителем NULL. Это правило было реализовано средствами СУБД на этапе создании таблиц.
Второе правило - ссылочная целостность. Оно гласит, что если в отношении существует внешний ключ, то значение внешнего ключа должно либо соответствовать значению потенциального ключа некоторого кортежа в его базовом отношении, либо задаваться определителем NULL. Обеспечение соблюдения этого правила возложена целиком и полностью на программное обеспечение. На основе просчитанных, на этапе логического проектирования связей, были выделены сущности, первичные ключи в которых являлись внешними ключами других сущностей. В программное обеспечение были внесены алгоритмы, не позволяющие изменять либо удалять те записи в таблицах, значения которых являются внешним ключом в других таблицах.
Дополнительную проверку целостности данных в базе производит разработанная программа мониторинга целостности. Она просматривает базу данных в поисках нарушения целостности и в случае обнаружения сообщает об этом администратору данных. На основе полученной информации принимаются дальнейшие меры по восстановлению нарушенной целостности.
4) Шифрование. Данные, хранимые в данной базе данных, не является секретной информацией. Поэтому использование данного метода защиты информации в базе данных не оправдывает затрачиваемых средств на её реализацию. Данные по сети передаются в незашифрованном виде.
2. Программное обеспечение
Функциональное назначение программ.
К основным задачам, которые должны быть решены на этом этапе, относятся:
1) разработка пользовательского Web-интерфейса, позволяющего отображать необходимую информацию из базы данных, в соответствии с транзакциями (п. 1.1.2)
2) разработка Web-интерфейса для администраторов данных, с целью возможности управления данными базы.
Рассмотрим более подробно поставленные задачи. Каждую из них условно можно разделить на меньшие задачи, решение которых реализуют разработанные программные модули (скрипты). Таким образом, решение основных задач складывается из решений серии подзадач, к коим можно отнести следующие:
1.1) Вывод на первой странице сайта информации о последних добавлениях основных тематических разделов;
1.2) Создание интерактивной станицы сайта по игровому рубрикатору, отображающую информацию по выбранным пользователем игровым разделам с указанием ссылок на соответствующие ресурсы. Возможность осуществления поиска ссылок на игровые ресурсы по журнальным публикациям.
1.3) Создание интерактивной станицы сайта по журнальному рубрикатору, отображающую информацию по выбранным журнальным рубрикам с указанием ссылок на эти ресурсы.
1.4) Отображение архива номеров.
1.5) Вывод информации по выбранному пользователем ресурсу.
2) Создание интерактивных страниц, с помощью которых осуществляется добавление, изменение или удаление информации в базу.
Стандартные запросы к базе данных.
Решение каждой задачи основывается на построении соответствующих запросов к базе данных и обработке полученных результатов.
В программных модулях используются масса запросов, большинство из которых схожи по своей структуре. Описание всех запросов займет много места, поэтому далее будут рассмотрены для примера только некоторые запросы, сформулированные на трех языках: реляционное исчисление, реляционное исчисление кортежей, SQL.
Задача 1.1
Первая страница сайта:
Выдать последние 10 внесенных ссылок на игровые ресурсы из рубрики «Руководства и прохождения»:
На языке реляционной алгебры этот запрос можно записать в виде:
,
где
A - games.GameId
B - games.GrubricId
C - games.UploadTime
D - GamesNames.SymbolName
E - GamesNames.GameId
Так как средства языка не делают возможным сортировку и отбор некоторого количества требуемых кортежей, то это решается уже на программном уровне.
На языке реляционного исчисления кортежей этот запрос это можно сформулировать как
RANGE OF G IS Games
RANGE OF GN IS GamesNames
{G.GameId,G.GRubricId,G.UploadTime,GN.SymbolName |
(g)(gn)(G(g)GN(gn)(g.GameId=gn.GameId)((g.GrubricId='SOLUTION') (g.GrubricId='GUIDE')) ) }
Также как и в предыдущем случае, сортировка и лимитирование количества запросов осуществляется программным методом.
Средства языка SQL позволяют встроенными методами произвести сортировку результата по указанному полю и лимитирование. Таким образом, на SQL этот запрос выглядит как:
SELECT games.GameId,GRubricId,UploadTime,SymbolName FROM games LEFT JOIN GamesNames USING (GameId) WHERE UCASE(GRubricId)='SOLUTION' OR UCASE(GRubricId)='GUIDE' ORDER BY UploadTime DESC LIMIT 10
Задача 1.2
Пользователь первоначально выбирает игровые рубрики, по которым он желает получить имеющуюся информацию, и алфавитный раздел, для удобства простмотра выбранных результатов алфавитными блоками. Данный результат получается объединением серий запросов. Рассмотрим, для примера, один из таких запросов. Остальные полностью аналогичны.
Итак, «необходимо вывести список игр, название которых начинается на букву A, по которым есть демоверсии».
Язык реляционной алгебры:
, где
A - GamesNames.SymbolName
B - GamesNames.Litera
C - Demoversions.GameId
D - GamesNames.GameId
Язык реляционного исчисления кортежей:
RANGE OF D IS Demoversions
RANGE OF GN IS GamesNames
{GN.SymbolName |
(d)(gn)( D(d)GN(gn)(d.GameId=gn.GameId)(gn.Litera='A') ) }
Язык SQL:
SELECT B.SymbolName FROM Demoversions A LEFT JOIN GamesNames B USING (GameId) WHERE B.Litera LIKE `A'
Заключение
В данной работе проводилась разработка базы данных и программного обеспечения для сайта игрового журнала.
Была показана актуальность поставленной задачи. Были проведен анализ программного обеспечения, по результатам которого был выбран язык программирования PHP и была показана возможность реализации базы данных под управлением СУБД MySQL.
В результате анализа предметной области были определены сущности предметной области и связи между ними. Произведена типизация связей, установлены кардинальности отношений, создана логическая схема базы данных.
Разработано программное обеспечение, позволяющее решить вопросы о
возможности удаленного администрирования данных по средствам Web-интерфейса;
способе получения, обработки запросов от пользователей (посетителей сайта) и выдачи соответствующих результатов.
Разработана структура готовых запросов к базе данных. Однако, из-за большого числа этих запросов, приведены в качестве примеров только некоторые из них. Разработана методология защиты базы данных, включающая стратегию резервного копирования, парольную идентификацию, средства мониторинга для проверки целостности информации в базе данных. В результате выполнения дипломной работы создана база данных и программное обеспечение по её обработке.
В результате тестирования программного обеспечения отклонения и сбоев в функционировании не обнаружено.
В настоящее время система проходит опытную эксплуатацию в организации заказчика.Размещено на Allbest.ru
Подобные документы
Разработка и программная реализация сайта и базы данных, наполнение базы данных тестовой информацией о товарах. Инструментальные средства создания сайта. Организация тестирования сайта, модуль визуализации интерфейса. Создание запросов в базе данных SQL.
курсовая работа [1,4 M], добавлен 24.12.2012Разработка структуры базы данных сайта. Установка и настройка требуемого программного обеспечения. Анализ интерфейса программы. Создание формы обратной связи. Формирование дизайна, соответствующего требованиям заказчика. Выбор методики тестирования.
дипломная работа [2,0 M], добавлен 22.03.2018Инструментальные возможности для реализации программы. Позиционирование сайта в Интернете, разработка дизайна и информационное наполнение. Создание анимированного баннера и добавления в поисковые системы для продвижения данного сайта в Интернете.
курсовая работа [1,9 M], добавлен 29.09.2012Формулировка требований к разработке и оформлению информационного сайта предприятия. Описание архитектуры сайта, меню навигации и алгоритма работы, листинг программного кода. Выбор серверной части и процесс отладки. Методы продвижения сайта в Интернете.
курсовая работа [4,6 M], добавлен 18.01.2014Выбор инструментальных и программных средств для создания сайта. Структура программного продукта. Создание сайта при помощи программы WordPress. Тестирование разработанной программы. Разработка структуры и дизайна сайта. Наполнение сайта контентом.
курсовая работа [1,0 M], добавлен 09.01.2014Понятие Internet как глобальной мировой системы передачи информации. Анализ системы World Wide Web, ее особенности. Рассмотрение главных целей сайта, создание сайта для магазина продуктов питания. Этапы разработки дизайна сайта и создание базы данных.
курсовая работа [2,1 M], добавлен 13.07.2012Создание базы данных, построение на ее основе информационной системы в виде веб-сайта. Обоснование и выбор системы управления базой данных. Датологическое проектирование, разработка алгоритма решения задачи, создание форм. Результаты обработки данных.
отчет по практике [904,1 K], добавлен 13.04.2015Проектирование web-сайта. Пользовательские персонажи, детальная концепция сайта. Разработка скелетной схемы страниц, информационной архитектуры. Создание прототипа web-сайта. Выбор среды разработки. CMS системы и их анализ. Стадии проектирования сайта.
курсовая работа [346,7 K], добавлен 18.09.2016Технологии создания web-страниц. Появление Active Server Pages. Разработка динамического web-сайта на asp.net. Создание дизайна и каркаса сайта с использованием стандартных HTML таблиц. Проектирование базы данных на основе ado.net и подключение к ней.
контрольная работа [2,4 M], добавлен 24.05.2019Общее описание разрабатываемого веб-сайта. Создание модуля учета средств для разработки программного продукта. Разработка дизайна. Редактирование веб-сайта в CMS Worspress. Разработка методических указаний для продукта. Система управления базами данных.
дипломная работа [1,8 M], добавлен 10.07.2017
