Создание игрового сайта в Интернете
Проектирование и реализация информационной системы по поддержке игрового сайта в Интернете. Создание и разработка базы данных для хранения информации на основе требований заказчика и программного обеспечения для обработки данных: структура и дизайн сайта.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 21.11.2010 |
| Размер файла | 602,5 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
59
Содержание
- Введение
- 1. Специальная часть
- 1.1 Спецификация требований
- 1.1.1 Требования к данным
- 1.1.2 Требования к транзакциям
- Этап 1. Построение локальной концептуальной модели данных
- Этап 1.1 Определение типов сущностей
- Этап 1.2 Определение типов связей
- Этап 1.3 Определение атрибутов и связывание их с типами сущностей и связей
- Этап 1.4 Определение атрибутов, являющихся потенциальными и первичными ключами
- Этап 1.5 Создание диаграммы «сущность-связь»
- Этап 2. Построение и проверка локальной логической модели данных
- Этап 2.1 Преобразование локальной концептуальной модели данных в локальную логическую модель
- Этап 2.2 Определение набора отношений исходя из структуры локальной логической модели данных
- Этап 2.3 Проверка модели с помощью правил нормализации
- Этап 2.4 Проверка модели в отношении транзакций пользователей
- Этап 2.5 Создание диаграммы «сущность-связь»
- Этап 3. Перенос глобальной логической модели данных в среду целевой субд
- Этап 3.1Проектирование таблиц базы данных в среде целевой субд
- Этап 4. Разработка механизмов защиты
- 2. Программное обеспечение
- Заключение
Введение
Анализ поставленной задачи.
Задание данного проекта: спроектировать и реализовать информационную систему по поддержке игрового сайта в Интернете. Для решения поставленной задачи нужно: спроектировать и создать базу данных для хранения информации на основе требований заказчика и программное обеспечение для обработки данных.
Обоснование актуальности задачи.
Актуальность задачи продиктована требованиями заказчика. И, принимаясь за работу, мне в первую очередь требовалось размышлять не о том, зачем это нужно, а о том, как это реализовывать.
Если же в общих чертах изложить те причины, которые толкнули заказчика на то, чтобы поручить мне данную работу, то в их числе можно выявить следующие ключевые:
1. Коренная перестройка (практически с нуля) и кардинальное расширение игрового сайта. Цель - сделать его максимально привлекательным для посетителей.
2. Наряду с развитием сайта ставилась цель, придав максимально возможную популярность сайту, тем самым сделать более известным журнал "Игромания". Целевая аудитория в данном случае - онлайновая компьютерно-игровая, не читающая печатные игровые издания.
3. Помимо прочего, сайт был предназначен для раскручивания любых других проектов издательского дома "Игромания-М", имеющих игровую или околоигровую тематику.
Структура сайта, которую предстояло выстраивать, и его дизайн автоматически оказывались детерминированными первым и вторым пунктами. Третий пункт далее можно не учитывать (кроме отдельных случаев) в силу его опциональности и, при условии реализации первого и второго пункта, элементарной воплотимости в любых желаемых заказчиком формах и проявлениях.
При первом же осмыслении предстоящей перестройки сайта стало очевидным, что основным ядром сайта выступает глобальная база данных, объединяющая в себе тонны всевозможных информационных блоков. Все прочее, что было и есть на сайте, уже либо является отдельно стоящими в той или иной степени простыми модулями, либо же и чаще всего - надстройками для означенной глобальной базы.
Анализ программного обеспечения.
Выбор методов доступа к базе данных.
Сравним способы реализации доступа к базе данных. Схематически можно представить взаимодействие базы данных и WEB-сервера так:
CGI - Common Gateway Interface.
Первым способом стали приложения Common Gateway Interface (CGI), поскольку спецификация CGI позволяет браузеру вызвать тот или иной исполняемый модуль или скрипт на Web-сервере, который мог обратиться с запросом к базе данных, построить в HTML-кодах страницу результатов и передать ее обратно Web-серверу, который же, в свою очередь, отсылал результаты браузеру. CGI-приложения могут содержать вызовы других программных (написанных, например, на С++) или командных (.bat, .cmd) файлов. С помощью CGI-cкриптов, а точнее на языке PERL (Practical Extraction and Reporting Language), построено немало интерактивных Web-приложений. К сожалению, каждый такой скрипт исполняется как иной, нежели Web-сервер, процесс, что быстро "съедает" ресурсы даже достаточно "навороченной" по сегодняшним меркам машины, особенно при большом количестве заходов на сервер.
JAVA
Java - это оригинальный язык программирования, разработанный корпорацией Sun Microsystems и продвигаемый в настоящее время на рынке фирмой JavaSoft. Исходно он задумывался, как язык программирования для поддержки среды связанных в сеть компьютеров и встроенных систем.
Значения языка Java и связанных с ним технологий в последнее годы стремительно возрастает. Java является объектно-ориентированным языком программирования со строгим контролем типов, который интересен, прежде всего, возможностью построения Web-приложений и серверных приложений.
Язык Java особенно интересен из-за его платформенно-независимой архитектуры. Текст байт-кода одинаково легко интерпретируется на любой платформе или же транслируется в характерные для неё методы. [9]
PERL
Perl - интерпретируемый язык, приспособленный для обработки произвольных текстовых файлов, извлечения из них необходимой информации и выдачи сообщений. Perl также удобен для написания различных системных программ. Этот язык прост в использовании, эффективен, но про него трудно сказать, что он элегантен и компактен. Perl сочетает в себе лучшие черты C, shell, sed и awk, поэтому для тех, кто знаком с ними, изучение Perl-а не представляет особого труда. Синтаксис выражений Perl-а близок к синтаксису C. В отличие от большинства утилит ОС UNIX Perl не ставит ограничений на объем обрабатываемых данных и если хватает ресурсов, то весь файл обрабатывается как одна строка. Рекурсия может быть произвольной глубины. Хотя Perl приспособлен для сканирования текстовых файлов, он может обрабатывать так же двоичные данные и создавать .dbm файлы, подобные ассоциативным массивам. Perl позволяет использовать регулярные выражения, создавать объекты, вставлять в программу на С или C++ куски кода на Perl-е, а также позволяет осуществлять доступ к базам данных. [8]
PHP - Personal Home Page Tools.
Модуль PHP начал жизнь как простая небольшая CGI оболочка, написанная на Perl. Чтобы избавиться от значительных непроизводительных затрат из-за необходимости запуска Perl при каждом обращении к серверу в стандартном обращении CGI. Первоначально использовался для маленьких Internet-страниц. Позднее был встроен инструмент для включения SQL в WEB-страницы. Это была CGI-оболочка, которая анализирует запросы SQL и облегчает создание форм и таблиц, основанных на этих запросах.
PHP/FI версии 2.0 - полная перезапись из этих двух пакетов, объединенных в одиночную программу. Это теперь развилось по сути в простой язык программирования, внедренный внутрь HTML файлов. PHP/FI сегодня используется больше для создания целых WEB серверов, чем для малых домашних страниц. Модуль устраняет потребность в многочисленных малых cgi программах на Perl, позволяя поместить простые скрипт-программы непосредственно в ваши HTML файлы. Пакет также упрощает управление большими WEB серверами, помещая все компоненты WEB страницы в одиночном файле HTML. Встроенная поддержка различных баз данных делает тривиальной разработку WEB страниц с доступом к базам данных. Многие находят, что иметь дело с внедренным в html-документы языком намного проще, чем создавать отдельные HTML и CGI файлы. [10] [4]
Учитывая удобство и простоту использования РНР и лучшую программную совместимость с другими скриптами имеющимися на сервере и написанными на РНР, остановим выбор на этом программном модуле.
Типы архитектур организации данных.
Для разных задач целесообразно использовать различные архитектуры баз данных, поскольку, конечно, базу данных сведений о сотрудниках какого-то небольшого коллектива и базу данных о каком-нибудь банке, имеющем филиалы во всех концах страны, надо строить по-разному.
Процесс определения того, какая база данных более подходит для конкретного приложения, называется масштабированием.
В следующих разделах коротко рассмотрены четыре архитектуры баз данных [1]:
· Автономные
· Файл-серверные
· Двухуровневая архитектура «клиент/сервер»
· Трехуровневая архитектура
1. Автономные базы данных
Автономные локальные базы данных являются наиболее простыми. Они хранят свои данные в локальной файловой системе на том компьютере, на котором установлены; система управления и машина базы данных, осуществляющая к ним доступ, находится на том же самом компьютере. Сеть не используется. Поэтому разработчику автономной базы данных не приходится иметь дело с проблемой параллельного доступа, когда два человека пытаются одновременно изменить одну и ту же запись, потому что такого никогда не может быть. Вообще, автономные базы данных не используются для приложений, требующих значительной вычислительной мощности, потому что процессорное время будет потрачено на выполнение манипуляций с данными и в целом будет потеряно для приложения.
Автономные базы данных полезны для развития тех приложений, которые распространены среди многих пользователей, каждый из которых поддерживает отдельную базу данных. Это, например, приложения, обрабатывающие документацию небольшого офиса, кадровый состав небольшого предприятия, бухгалтерские документы небольшой бухгалтерии. Каждый пользователь такого приложения манипулирует своими собственными данными на своем компьютере. Пользователю нет необходимости иметь доступ к данным любого другого пользователя, так что отдельная база данных здесь вполне приемлема.
2.Файл-серверные базы данных
Файл-серверные базы данных отличаются от автономных тем, что они могут быть доступны многим клиентам через сеть. Это очень удобно, так как изменения в таких базах данных видят все пользователи. Например, базу данных сотрудников крупного учреждения целесообразно делать именно такой, чтобы администраторы отдельных подразделений обращались к ней, а не заводили у себя локальные базы данных (при этом нужно сделать так, чтобы сохранялась конфиденциальность информации и чтобы каждый администратор видел только ту информацию, которая относится к его подразделению).
Сама база данных хранится на сетевом файл-сервере в единственном экземпляре. Для каждого клиента во время работы создается локальная копия данных, с которой он манипулирует. При этом возникают (и решаются) проблемы, связанные с возможным одновременным доступом нескольких пользователей к одной и той же информации. Например, при проектировании приложений, работающих с подобными базами данных, должны быть решены такие проблемы: что делать, если пользователь прочел некоторую запись и, пока он ее просматривает и собирается изменить, другой пользователь меняет или удаляет эту запись.
Одним из недостатков баз данных файл-сервер является непроизводительная загрузка сети. При каждом запросе клиента данные в его локальной копии полностью обновляются из базы данных на сервере. Даже если запрос относится всего к одной записи, обновляются все записи данных. Если записей в базе данных много, то даже при небольшом числе клиентов сеть будет загружена очень основательно, что серьезно скажется на скорости выполнения запросов.
Другой недостаток связан с тем, что забота о целостности данных при такой организации работы возлагается на программы клиентов. Если они недостаточно тщательно продуманы, в базу данных легко занести ошибки, которые могут отразиться на всех пользователях.
3. Двухуровневая архитектура «клиент/сервер»
Для больших баз данных с множеством пользователей часто используются базы данных на платформе клиент/сервер. В этом случае доступ к базе данных для группы клиентов выполняется специальным компьютером -- сервером. Клиент дает задание серверу выполнить те или иные операции поиска или обновления базы данных. И мощный сервер, ориентированный на операции с запросами самым оптимальным способом, выполняет их и сообщает клиенту результаты своей работы.
Подобная организация работы повышает эффективность выполнения приложений за счет использования мощности сервера, разгружает сеть, обеспечивает хороший контроль целостности данных.
В базах данных клиент/сервер возникает дополнительная проблема -- спроектировать приложение так, чтобы оно максимально использовало возможности сервера и минимально нагружало сеть, передавая через нее только минимум информации.
4 Трехуровневая
Это новый и многообещающий путь обработки данных в сети.
Наиболее распространен трехуровневый вариант:
На нижнем уровне на компьютерах пользователя расположены приложения клиентов, обеспечивающие пользовательский интерфейс.
На втором уровне расположен сервер приложений, обеспечивающий обмен данными между пользователями и распределенными базами данных. Сервер приложений размещается в узле сети, доступном всем клиентам
На третьем уровне расположен удаленный сервер баз данных, принимающий информацию от серверов приложений и управляющий ими.
Это наиболее сложная и гибкая организация баз данных.
В глобальной сети Интернет, наиболее распространена двухуровневая архитектура «клиент-сервер». Именно такой тип архитектуры представлен в моем случае. Получение заданий на поиск от клиентов, обработка и вывод результатов, а также обмен данными с базой данных производит один компьютер - сервер.
1. Специальная часть
сайт игровой база данный
Анализ предметной области.
База данных должна содержать таблицы и поля для хранения необходимой информации, определенной далее в тексте спецификаций требований.
Выбор системы управления баз данных (СУБД).
Интернет-сервер, на котором будет реализован этот этап, к сожалению, ограничен в выборе как программного обеспечения, так и в выборе СУБД. Поэтому, в качестве целевой СУБД для реализации проекта будет использован MySQL. Однако, стоит упомянуть преимущества выбора данной СУБД по сравнению с другими СУБД. [5] [6]
· Быстродействие. MySQL - достаточно быстродействующая СУБД. Разработчики склоняются к мнению, что СУБД MySQL является одной из самых быстрых баз данных из имеющихся на современном рынке. В этом можно убедиться, посетив Web-узел http://www.mysql.com/benchmark.html. Эта страница позволяет делать сравнительную проверку производительности на Web-узле MySQL.
· Простота использования. СУБД MySQL является высокопроизводительной и относительно простой в использовании СУБД, которую значительно проще инсталлировать и администрировать, чем многие большие системы.
· Поддержка языка запросов. MySQL «понимает» команды языка SQL. MySQLтакже поддерживает интерфейс ODBC (Open Database Connectivity), протокол интерфейса с базами данных, разработанный компанией Microsoft.
· Возможности. Сервер позволяет одновременно подключаться неограниченному количеству пользователей. Доступ к серверу можно осуществить в интерактивном режиме с помощью различных интерфейсов, позволяющих вводить запросы и просматривать полученные результаты: это программы-клиенты, работающие с командной строкой, Web-браузеры. Кроме того, в наличии имеются программные интерфейсы для таких языков, как C, Perl, Java, PHP и Python.
· Взаимодействие и безопасность. MySQL предназначена для работы в сети и может быть доступна для работы через Интернет, таким образом, с данными можно работать в любой точке земного шара. Но при этом СУБД MySQL снабжена развитой системой защиты от несанкционированного доступа.
· Переносимость. СУБД MySQL отлично работает как под управлением самых различных версий UNIX, так и под управлением систем, не использующих UNIX, таких как Windows и OS/2. СУБД MySQL работает как на домашних ПК, так и на мощных серверах.
Доступ на создание базы данных и таблиц в ней будет осуществляться через командную строку.
Реляционная модель данных.
В основе реляционной модели лежит понятие отношения, представляющего собой подмножество декартового произведения доменов. Домен - это некоторое множество элементов (например, множество целых чисел или множество допустимых значений, которые может принимать объект по некоторому свойству и т.п.). Отношение R на множествах доменов D1,D2,…,Dn называется подмножеством декартова произведения D1хD2х…хDn . [1]
Для получения информации из отношений необходим язык манипулирования данными, выполняющий соответствующие операции над отношениями. Наиболее важной частью языка манипулирования данными является его раздел для формулировки запросов. Поскольку запросы в общем случае представляют собой произвольные функции над отношениями, необходимо решить вопрос о требуемой выразительности языка запросов. Для исследования этого вопроса были разработаны три абстрактных теоретических языка:
1) реляционная алгебра;
2) реляционное исчисление с переменными - кортежами;
3) реляционное исчисление с переменными - доменами.
Языки запросов первого типа - алгебраические языки - позволяют выражать запросы средствами специализированных операторов, применяемых к отношениям.
Языки второго и третьего типов - языки исчисления - позволяют выражать запросы путем спецификации предиката, которому должны удовлетворять требуемые кортежи (или домены). Эти языки служат эталоном для оценки существующих реальных языков запросов. Они были предложены Коддом для представления минимальных возможностей любого разумного языка запросов для реляционной модели данных.
Реляционная алгебра и реляционное исчисление в своей основе эквивалентны. Первым это показал Кодд, разработав алгоритм редукции, с помощью которого любое выражение исчисления можно преобразовать в семантически эквивалентное выражение алгебры. [11]
Реальные языки (ISBL, SEQUEL, QBE, SQL и др.) обеспечивают не только функции соответствующего теоретического языка или их комбинации, но и реализуют некоторые дополнительные операции - арифметические операции, команды присваивания и печати и т.п.
Проектирование базы данных.
Проектирование базы данных - процесс создания проекта базы данных, предназначенной для поддержки функционирования предприятия и способствующей достижению его целей.
Существует поэтапная методология проектирования базы данных, основу которой составляют 3 этапа: концептуальное, логическое и физическое проектирование базы данных. [1]
· Концептуальное проектирование - создание концептуального представления базы данных, включающее определение типов важнейших сущностей и существующих между ними связей.
· Логическое проектирование - преобразование концептуального представления в логическую структуру базы данных, включая проектирование отношений.
· Физическое проектирование - принятие решения о том, как логическая модель будет реализована в базе данных, создаваемой с помощью выбранной СУБД.
1.1 Спецификация требований
Выполнение фазы сбора и анализа требований пользователей, являющихся первой в цикле разработки приложений баз данных, осуществлялось в офисе фирмы «ООО Игромания-М». Был проведен опрос сотрудников, работающих на должности редакторов. Результатом выполнения этой фазы разработки проекта явилась подготовка спецификаций требований. В этих спецификациях зафиксированы требования к информации, которая будет помещена в создаваемую базу данных и определены транзакции, необходимые для нормального функционирования сайта.
1.1.1 Требования к данным
1) Статья (Article), выложенная на сайте может быть либо игровой тематики, либо неигровой тематики
2) Ежемесячно выпускается журнал с прилагаемым компакт-диском. Каждый номер журнала однозначно характеризуется уникальным порядковым значением (сквозная нумерация журналов). Если статья публиковалась в журнале/на диске, то необходимо отметить номер, год журнала/диска, в котором она публиковалась.
3) По каждой статье должна запоминаться информация об авторе: его имя и псевдоним.
4) По каждой игре могут писаться статьи игровой тематики (игровая статья). При этом, любая игровая статья пишется только по одной игре.
5) По каждой имеющейся игре должна храниться следующая информация: название игры, жанр, разработчик, издатель, год выхода, минимальные и рекомендуемые системные требования, возможность поддержки многопользовательского режима, количество CD.
6) Имеется «игровой рубрикатор» включающий следующие рубрики:
a. Руководства и прохождения (Solution and Guides)
b. Патчи (Patches)
c. Обои (Wallpapers)
d. Демо-версии (Demoversions)
e. Геймхакинг (Gamehacking), включающий в себя подрубрики:
i. Сheats
ii. Hex Cheats
iii. Easter Eggs
iv. Ресурсы
v. Вскрытие (продублированая рубрика из «журнального рубрикатора»)
f. Трейнеры (Trainers)
g. Видеоролики (Videorollics)
h. Скриншоты ( Screenshots)
i. Темы рабочего стола (Desktop)
7) Рубрики «Руководство и прохождения» и «Геймхакинг» за исключением подрубрики «вскрытие» включают статьи игровой тематики. Подрубрика «вскрытие» из рубрики «Геймхакинг» взята и полностью дублирует рубрику из журнального рубрикатора.
8) Часть игровых статей публиковалась либо в журнале, либо на прилагаемом к нему компакт-диске. Все журналы с дисками образуют архив.
9) Информация по патчам должна включать в себя такие данные как:
a. Игра, для которой выпущен патч
b. Версия программного продукта
c. Размер
d. Время официального выхода
e. Комментарий
f. До 10 возможных ссылок на ресурс.
10) Раздел по обоям должен включать в себя такие данные как:
a. Игра по которой собрана коллекция обоев
11) Информация по демоверсиям должна включать в себя такие данные как:
a. Демоверсия какой игры представлена
b. Версия программного продукта
c. Размер
d. Время официального выхода игры
e. Комментарий
f. До 10 возможных ссылок на ресурс.
12) Раздел «трейнеры» должен включать в себя такие данные как:
a. К какой игре относится данный программный продукт
b. Версия программного продукта
c. Размер
d. Комментарий
e. Ссылка на скачиваемый файл
13) Информация по видеороликам должна включать в себя такие данные как:
a. Игра, к которой относится видеоролик
b. Размер видеоролика
c. Комментарий
d. До 10 возможных ссылок на ресурс.
14) Имеется, составленный по соответствующим рубрикам из журнала, «журнальный рубрикатор». В этом рубрикаторе отражены рубрики неигровой тематики, в которые, соответственно включаются статьи неигровой тематики, точнее околоигровой тематики (в дальнейшем для простоты будет упоминаться именно первый вариант определения). Часть этих статей взято из архивов журнала. Вот эти рубрики:
a. R&S: В разработке
b. R&S: В разработке: Краткие статьи
c. R&S: Вердикт
d. R&S: Вердикт: Краткие обзоры
e. Рецензии по демо-версиям
f. Deathmatch
g. Территория разлома
h. Вскрытие
i. Железный цех
j. Горячая линия
k. Самопал
l. Интернет
m. Атихакер
n. Матрица
o. МатрицаПлюс
p. КОДекс
q. Вне компьютера
15) Некоторые статьи неигровой (околоигровой) тематики могут упоминать ссылки на игры. Эти ссылки необходимо будет фиксировать.
16) По любому ресурсу должен запоминаться момент появления его на сайте для возможности дальнейшего отображения последних добавлений.
1.1.2 Требования к транзакциям
К основным транзакциям, которые должны выполняться программой сайта относятся следующие:
1. составление списка последних добавлений разделов
a) «Руководства и прохождения»
b) «Демоверсии»
c) «Видеоролики»
d) «Патчи»
e) «Геймхакинг»
f) «Трейнеры»
g) «Обои»
для их дальнейшего отображения на первой странице сайта.
2. составление списков игровых ресурсов игрового рубрикатора, отсортированных в алфавитном порядке
3. составление списков статей из выбранных журнальных рубрик
4. составление списков архивных номеров отсортированных по порядковым номерам (происходящим от времени выхода).
5. отображение в статьях её авторов.
6. способность игрового рубрикатора производить поиск по материалам журнального рубрикатора, которые имеют игровую принадлежность (с соответствующим фиксированием в базе данных), и выводить их в отсортированном порядке.
Этап 1. Построение локальной концептуальной модели данных
Приступая к разработке локальной концептуальной модели данных, прежде всего, следует выявить различные компоненты этой модели, используя имеющиеся спецификации требований. В каждую создаваемую модель входят следующие компоненты:
· типы сущностей
· типы связей
· атрибуты
· домены атрибутов
· потенциальные ключи
· первичные ключи
Этап 1.1 Определение типов сущностей
Начнем работу с того, что определим основные типы сущностей исходя из имеющихся спецификаций. Анализ показывает, что основными сущностями, упоминаемыми в спецификациях, являются следующие:
авторы - Authorsжурналы и диски - Archiveнеигровая статья - NonGameArticleдемоверсии - Demoversionsтрейнеры - Trainersпатчи - Patches |
игровая статья - GameArticleигра - Gameигровая рубрика - GameRubricжурнальная рубрика -
|
Этап 1.2 Определение типов связей
Следующее задание состоит в определении типов связей, существующих между отдельными сущностями. Как правило, они выражаются глаголами или глагольными сочетаниями. Для выявления всех возможных типов связей вновь обратимся к спецификациям. Результаты анализа представлены в таблице
|
Тип сущности |
Тип связи |
Тип сущности |
|
|
GameArticle (игровая статья) |
WrittenBy (написана)Published (была опубликована)AssociatedWith (связана с)BelongTo (Относится к) |
Authors (Авторы)Archive(журналы и диски)Game (Игра)GameRubric(игровая рубрика) |
|
|
NonGameArticle (неигровая статья) |
WrittenBy (написана)Published (была опубликована)CanAssociatedWith(может быть связана с) BelongToJR (Относится к) |
Author (Автор)Archive(журналы и диски)Game (Игра)JournalRubric(журнальная рубрика) |
|
Demoversions(Демоверсии) |
AssociatedWith (связаны с)BelongToG (Относится к) |
Game (Игра)GameRubric |
|
|
Trainers (Трейнеры) |
AssociatedWith (связаны с)BelongToG (Относится к) |
Game (Игра)GameRubric |
|
Patches(Патчи) |
AssociatedWith (связаны с)BelongToG (Относится к) |
Game (Игра)GameRubric |
|
Wallpapers(Обои) |
AssociatedWith (связаны с)BelongToG (Относится к) |
Game (Игра)GameRubric |
|
Videorollicks(Видеоролики) |
AssociatedWith (связаны с)BelongToG (Относится к) |
Game (Игра)GameRubric |
Определение кардинальности и уровня участия отдельных типов связей.
Следующий шаг - определение кардинальности и уровня участия для каждого типа связей, приведенных в таблице
Кардинальность любой связи может иметь значение либо «один к одному» (1:1), либо «один ко многим» (1:М), либо «многие ко многим». Для каждой связи требуется указать её кардинальность и, если возможно, верхний или нижний лимиты групп «М». Участие каждого из членов связи может быть определен либо как полное (тотальное), либо как частичное. Большую часть информации, необходимой для установления кардинальности и уровня участия сторон каждой связи, можно найти в спецификациях, приведенных выше. Однако, если содержащихся в спецификациях сведений не достаточно для однозначного определения свойств некоторых связей, для прояснения ситуации следует обратиться к пользователям.
Связь GameArticle WrittenBy Authors. В спецификации эта связь определяется следующей фразой: «У каждой статьи есть авторы». Кардинальность данной связи можно определить, как 1:N. Поскольку любая статья имеет автора, степень участия сущности GameArticle в связи WrittenBy является полной.
Что бы лучше разобраться в сути данной связи, рассмотрим её в обратном направлении - Authors Write GameArticle (Авторы пишут игровую статью). Текст спецификаций не содержит явного описания связи Write, поэтому следует обратиться к пользователям и задать им интересующий нас вопрос:
Вопрос: Каждый автор пишет только одну игровую статью?
Ответ: Нет.
Полученный ответ указывает, что каждый автор может писать несколько игровых статей и, следовательно, связь Write имеет так же кардинальность 1:М. Участие сущности Author в связи Write тотальной не будет, так как не все авторы пишут игровые статьи.
Таким образом, кардинальность данной связи определяется как M:N.
Теперь мы имеем возможность ссылаться на связь между сущностями GameArticle и Authors, либо как на связь GameArticle WrittenBy Authors, либо как на связь Authors Write GameArticle. Мы имеем право выбрать любой вариант. Остановимся на следующем:
Рисунок 1.
Полностью аналогичной является связь NonGameArticle WrittenBy Authors:
Рисунок 2.
Связь GameArticle Published Archive (Игровые статьи могли публиковаться в журнале или на диске). В спецификации эта связь определяется вытекает из восьмого пункта. Особенности данной связи дополнительно обсуждались с конечными пользователями, в результате чего выяснилось, что любая статья из журнала могла публиковаться не более одного раза. Поэтому кардинальность данной связи можно определить как 1:1. А поскольку не каждая статья помещенная на сайте была опубликована в журнале, степень участия сущности GameArticle в связи Published не является тотальной.
Рассмотрим данную связь в обратном направлении: Archive involve GameArticle (Журнал включает в себя игровые статьи). Так как в каждом номере опубликовано некоторое множество статей, то степень кардинальности определяется как 1:M. Но поскольку в архиве журналов опубликованы не все статьи помещенные на сайт, степень участия сущности Archive в связи involve не является тотальной.
При отображении некоторой связи на диаграмме «сущность-связь» (ER-диаграмме), всегда следует использовать вариант с более высоким уровнем кардинальности. Таким образом:
Рисунок 3.
Связь NonGameArticle Published Archive полностью аналогична связи GameArticle Published Archive. Поэтому для этой связи результатом будет:
Рисунок 4.
Связь GameArticle AssociatedWith Game. В спецификации эта связь определяется следующей фразой: «Любая игровая статья пишется только по одной игре». Кардинальность данной связи равна 1:1 (с одной статьей связана только одна игра). Так как любая игровая статья пишется по игре, то степень участия сущности GameArticle в связи AssociatedWith будет тотальной.
Game DescribedBy GameArticle (Игра описана в статье). По одной игре могут быть несколько игровых статей. Следовательно, степень кардинальности этой связи равна 1:M. Степень тотальности сущности Game в связи DescribedBy тотальной не будет, в силу того, что не по каждой игре может быть написана статья.
Окончательным вариантом кардинальности будет:
Рисунок 5.
Связь GameArticle BelongTo GameRubric. В спецификации эта связь определяется седьмым пунктом. (Любая игровая статья отражена в одном из разделов игрового рубрикатора). Одна статья может входить только в одну из рубрик, следовательно, кардинальность данной связи равна 1:1. Так как ЛЮБАЯ статья входит в игровой рубрикатор, то степень участия сущности GameArticle в связи BelongTo будет тотальной.
GameRubric Unite GameArticle (Игровой рубрикатор объединяет игровые статьи). Каждая рубрика может объединять множество статей. Следовательно, кардинальность данной связи равна 1:M. Степень участия сущности GameRubric в связи Unite тотальной не является, так как не все рубрики объединяют в себе игровые статьи.
Окончательным вариантом кардинальности будет:
Рисунок 6.
Связь NonGameArticle CanAssociatedWith Game. В спецификации эта связь определяется пятнадцатым пунктом. В неигровой статье могут упоминаться несколько игр. Кардинальность данной связи равна 1:N. Так как только в некоторых статьях неигровой тематики может быть упоминания по играм, то степень участия сущности NonGameArticle в связи CanAssociatedWith не будет тотальной.
Game CanDescribedBy NonGameArticle (Игра может быть описана в неигровой статье). Одна и та же игра может неоднократно упоминаться в статьях как игровой так и неигровой тематики. Следовательно, степень кардинальности этой связи равна 1:M. Степень участия сущности Game в связи CanDescribedBy тотальной не будет, в силу того, что не по каждой игре писалась статья неигровой тематики.
Таким образом, кардинальность данной связи устанавливается как N:M и мы имеем право выбирать для отображения на ER-диаграмме любую из двух возможных связей - как CanAssociatedWith, так и CanDescribed. Остановимся на варианте Game CanDescribedBy NonGameArticle:
Рисунок 7.
Связь NonGameArticle BelongToJR JournalRubric.
В спецификации эта связь определяется четырнадцатым пунктом.
(ЛЮБАЯ неигровая статья отражена в ОДНОМ из разделов журнального рубрикатора).
Кардинальность данной связи равна 1:1. Степень участия сущности NonGameArticle в связи BelongToJR будет тотальной.
JournalRubric UniteNGA NonGameArticle (Игровой рубрикатор объединяет игровые статьи). Каждая рубрика может объединять множество статей. Следовательно, кардинальность данной связи равна 1:M. Степень участия сущности JournalRubric в связи UniteNGA является тотальной, так как все рубрики объединяют в себе все неигровые статьи.
Окончательным вариантом кардинальности будет:
Рисунок 8.
Связь Demoversions AssociatedWith Game.
В спецификации эта связь неявно описана в первом подпункте одиннадцатого пункта, из которого следует, что демоверсия связана с игрой.
Кардинальность данной связи равна 1:1. Одна демоверсия может быть только по одной игре.
Степень участия сущности Demoversions в связи AssociatedWith будет тотальной.
Связь Game has Demoversions.
Кардинальность данной связи равна 1:M. По одной игре может быть несколько демоверсий.
Степень участия сущности Game в связи has не будет тотальной, так как к игре могут быть не только демоверсии.
Рисунок 9.
Связь Demoversions BelongToG GameRubric.
В спецификации эта связь определяется шестым пунктом.
Кардинальность данной связи равна 1:1.
СУ = тотальная
GameRubric Includes Demoversions
КС = 1:M
CУ = нетотальная
Рисунок 10.
Предварительная ER-диаграмма
Что бы разобраться с тем, как сущности связаны между собой через существующие между ними связи, проще всего представить всю ситуацию наглядно, в виде диаграммы «сущность-связь». Поэтому, на основе проведенного выше анализа связей, можем нарисовать предварительный вариант ER-диаграммы, содержащий основные сущности и связи, описанные в спецификациях. Общий вид этой диаграммы представлен на рисунке ER-1
Документирование типов связей
Этап 1.3 Определение атрибутов и связывание их с типами сущностей и связей
На этом этапе необходимо выявить все данные, описывающие сущности и связи, выделенные в создаваемой модели базы данных. Атрибуты отражают свойства типа сущностей или связей. Самый простой метод выявления атрибутов - после идентификации очередной сущности или связи в некоторой спецификации задаться вопросом: «Какую информацию требуется хранить о…». Ответ на этот вопрос ищется в тексте спецификации.
Большую часть ответа на этот вопрос ищется в тексте спецификации, однако часть атрибутов может быть дополнительно добавлена с учетом специфики в будущей программной реализации
Таблица. Атрибуты, принадлежащие сущностям.
|
Тип сущности |
Атрибут |
|
|
GameArticle |
PubPlace - место публикации.UploadTime |
|
|
NonGameArticle |
ArtName (название статьи)UploadTime |
|
|
Demoversions |
Size (размер демоверсии)Links (Link1, Link2, …, Link10) (ссылки)Comment (комментарий)UploadTime (время появления материала на сайте). Необходим для осуществления отображения последних добавлений на сайте |
|
|
Trainers |
Version (версия)CommentFileName (ссылка на файл для выкачивания)UploadTime |
|
|
Patches |
Version (версия)Comment PublishTime (срок выхода программы)UploadTime Links (Link1, Link2, …, Link10) |
|
|
Wallpapers |
UploadTimePicDir - каталог для хранения картинок |
|
|
Videorollicks |
Size (размер демоверсии)Links (Link1, Link2, …, Link10) (ссылки)Comment (комментарий)UploadTime |
|
|
Authors |
Name (Имя, Фамилия)Nick (Псевдоним) |
|
|
Archive |
Num (сквозной номер журнала)Year (год)Month (месяц) |
|
|
Game |
SymbolName (название игры)Genre (жанр)Developer (разработчик)Publisher (издатель)PublishYear (год выхода игры)SystemMin (минимальные системные требования)SystemMax (рекомендуемые системные требования)Multiplayer (поддержка режима MultiPlayer)AmountCD (кол-во CD)Litera (алфавитный раздел) |
|
|
GameRubric |
GRubric (название рубрики) |
|
|
JournalRubric |
JRubric (название рубрики) |
|
Документирование выделенных атрибутов.
Этап 1.4 Определение атрибутов, являющихся потенциальными и первичными ключами
На этом этапе для каждой сущности устанавливается потенциальный ключ (или ключи), после чего осуществляется выбор первичного ключа. Потенциальным ключом называется атрибут или минимальный набор атрибутов, позволяющий уникальным образом идентифицировать каждый её экземпляр. Для некоторых сущностей возможно наличие нескольких потенциальных ключей. В этом случае среди них нужно выбрать один ключ, который будет называться первичным ключом. Все остальные потенциальные ключи будут называться альтернативными ключами. При выборе первичного ключа среди нескольких потенциальных необходимо руководствоваться следующими рекомендациями:
§ Использовать потенциальный ключ с минимальным набором атрибутов.
§ Использовать тот потенциальный ключ, вероятность изменения значений которого минимальна.
§ Выбирать тот потенциальный ключ, который имеет минимальную вероятность потери уникальности значений в будущем.
§ Использовать потенциальный ключ, значения которого имеют минимальную длину (в случае текстовых атрибутов).
§ Останавливать выбор на потенциальном ключе, с которым будет проще всего работать (с точки зрения пользователя).
В процессе определения первичного ключа устанавливается, является данная сущность сильной или слабой. Если выбрать первичный ключ для данной сущности оказалось возможным, то такую сущность принять называть сильной. И наоборот, если выбрать первичный ключ для заданной сущности невозможно, то её называют слабой.
Таким образом, первичный ключ слабой сущности можно будет определить только после отображения этой слабой сущности и её связи с сущностью-владельцем в отношение, в котором упомянутая связь моделируется посредством помещения в данное отношение соответствующего внешнего ключа.
GameArticle(PubPlace,UploadTime)
Первичный ключ: нет.
Тип сущности: слабая
NonGameArticle(ArtName,UploadTime)
Первичный ключ: нет.
Тип сущности: слабая
Authors(Name, Nick)
В этой сущности, первичным ключом будет пара атрибутов Name и Nick, которая уникальным образом определяет каждого автора. Следуя рекомендациям выбора первичного ключа [1], мы искусственно введем атрибут AuthorId, который будет уникальным образом определять каждого автора. Этот атрибут мы определим, как первичный ключ, поскольку он лучше удовлетворяет рекомендациям по выбору первичного ключа и тогда пара Name и Nick станет альтернативным ключом. В качестве значений для нового первичного суррогатного ключа могут быть числа, однозначно определяющие каждую уникальную пару Name и Nick. Присвоение таких чисел будет решаться на программном уровне. Таким образом:
Authors(AuthorId, Name, Nick)
Первичный ключ: AuthorId (суррогатный)
Альтернативный ключ : Nick
Тип сущности: сильная
Archive(Num, Year, Month)
Первичный ключ: Num
Альтернативный ключ: Year+Month
Тип сущности: сильная
Game(GameId, SymbolName, Genre, Developer, Publisher, PublishYear, SystemMin, SystemMax, Multiplayer, AmountCD)
Первичный ключ: GameId (суррогатный)
Альтернативный ключ: SymbolName
Тип сущности: сильная
GameRubric(GRubricId, GRubric)
Первичный ключ: GrubricId (суррогатный)
Альтернативный ключ: GRubric
Тип сущности: сильная
JournalRubric(JrubricId, JRubric)
Первичный ключ: JrubricId (суррогатный)
Альтернативный ключ: JRubric
Тип сущности: сильная
Demoversions(NameId, Size, Links, Comment, UploadTime)
Первичный ключ: NameId (суррогатный)
Альтернативный ключ: Links.
Тип сущности: сильная
Trainers(NameId, Version, Comment, FileName, UploadTime)
Первичный ключ: NameId (суррогатный)
Альтернативный ключ: FileName.
Тип сущности: сильная
Patches(NameId, Version, Comment, PublishTime, UploadTime, Links)
Первичный ключ: NameId (суррогатный)
Альтернативный ключ: Links.
Тип сущности: сильная
Wallpapers(NameId, UploadTime, PicDir)
Первичный ключ: NameId (суррогатный)
Альтернативный ключ: PicDir.
Тип сущности: сильная
Videorollicks(NameId, Size, Links, Comment, UploadTime)
Первичный ключ: NameId (суррогатный)
Альтернативный ключ: Links.
Тип сущности: сильная.
Этап 1.5 Создание диаграммы «сущность-связь»
С целью получения наглядного представления основных сущностей и связей, определенных в спецификациях, мы перерисовали исходную ER-диаграмму, которая теперь имеет вид, показанный на рисунке ER-2.
Этап 2. Построение и проверка локальной логической модели данных
На этом этапе я перерабатываю локальную концептуальную модель данных с целью удаления из неё всех элементов, затрудняющих реализацию данной модели в среде реляционных СУБД. Кроме того, мы проверим созданную логическую модель данных, применив к ней правила нормализации и контроля возможности выполнения всех необходимых пользователю транзакций в том виде, в том виде, в котором они описаны в спецификациях. После завершения процесса преобразования структуры концептуальной модели с целью удовлетворения требований, предъявляемых к структуре данных со стороны реляционных СУБД, я буду ссылаться на преобразованную модель как на логическую модель данных. Конечной целью выполнения данного этапа является создание корректной, полной и точной локальной модели данных.
Этап 2.1 Преобразование локальной концептуальной модели данных в локальную логическую модель
На этом этапе я займусь преобразованием концептуальной модели данных с целью удаления из неё всех структур, реализация которых в СУБД реляционного типа затруднительна. Желаемый результат может быть достигнут посредством выполнения таких действий, как:
1. Удаление связей типа M:N.
2. Удаление сложных связей.
3. Удаление рекурсивных связей.
4. Удаление связей, имеющих атрибуты.
5. Удаление множественных атрибутов.
6. Перепроверка связей типа 1:1.
7. Удаление избыточных связей.
Удаление связей типа M:N
Как следует из рисунка 7 связь Game CanDescribedBy NonGameArticle меет кардинальность «многие ко многим» (M:N). Поэтому необходимо преобразовать связь CanDescribedBy в две связи типа 1:M (назовем их Attends (Выполняет) и Takes (Пишется к)), как показано на рисунке 11, для чего потребуется ввести новую слабую сущность Writing (Написание). Поскольку вновь созданная сущность является слабой, первичный ключ сущности Writing будет полностью или частично определяться сущностями-владельцами, т.е. сущностями Game и NonGameArticle.
Рисунок 11.
Аналогично преобразуем связи GameArticle WrittenBy Authors и NonGameArticle WrittenBy Authors
Рисунок 12.
Удаление сложных связей.
На этом этапе проводится удаление любых сложных (не бинарных) связей, присутствующих в концептуальной модели. Однако, на ER-диаграмме, показанной на рисунке ER-2 , связи подобного типа отсутствуют. Все связи в концептуальной модели являются бинарными.
Удаление рекурсивных связей.
На этом этапе проводится удаление любых связей, в которых сущность некоторого типа взаимодействует сама с собой. На ER-диаграмме, связи подобного типа отсутствуют.
Удаление связей, имеющих атрибуты.
Присутствие связей с атрибутами может указывать на наличие в модели еще не выделенных сущностей. Однако, в нашем случае, связи имеющие атрибуты отсутствуют.
Удаление множественных атрибутов.
В локальной концептуальной модели данных множественные атрибуты отсутствуют, поэтому перехожу к следующему этапу.
Перепроверка связей типа 1:1.
В локальной концептуальной модели данных связи тапа «один к одному» (1:1) отсутствуют, поэтому все связи и сущности сохраняются неизменными.
Создание диаграммы «сущность-связь».
ER-диаграмма, представляющая локальную концептуальную модель данных была показана на рисунке ER-2. При выполнении этапа 2.1 эта модель была пересмотрена и модифицирована с целью устранения структур данных, реализация которых в среде реляционных СУБД затруднительна. Вид модифицированной модели данных, с учетом всех внесенных в неё изменений, показан на рисунке ER-3. Полученную в результате внесения изменений модель данных правильнее будет называть локальной логической моделью данных.
Этап 2.2 Определение набора отношений исходя из структуры локальной логической модели данных
На этом этапе предстоит на основе созданной локальной логической модели данных определить наборы отношений, необходимые для представления сущностей и связей, входящих в представления отдельных пользователей о предметной области приложения.
Связи между сущностями моделируются с помощью механизма первичных и внешних ключей. Для описания состава всех создаваемых отношений будет использоваться язык DBDL (Database Definition Language). [1] Описание отношения на языке DBDL начинается с присвоения ему имени, за которым следует помещенный в скобки список имен его простых полей. Затем указывается первичный ключ отношения и все его альтернативные и/или внешние ключи. После описания внешних ключей может указываться ссылочный первичный ключ, если таковой имеется.
Связи, которая сущность имеет с другими типами сущностей, представляются с помощью механизма первичных и внешних ключей. Для принятия решения о том, откуда взять и куда поместить значения атрибута(ов) внешнего ключа, предварительно следует установить, какая из участвующих в связи сущностей является родительской, а какая - дочерней. Родительской считается сущность, которая передает копию набора значений своего первичного ключа в отношение, представляющее дочернюю сущность, где эти значения будут играть рол внешнего ключа.
Сильные типы сущностей.
Для каждой сильной сущности в локальной модели данных создается отношение, включающее все простые атрибуты этой сущности. В случае составных атрибутов (например, ссылок) в отношение включаются только составляющие их простые атрибуты.
Game(GameId, SymbolName, Genre, Developer, Publisher, PublishYear, SystemMin, SystemMax, Multiplayer, AmountCD)
Primary Key GameId
Alternate Key SymbolName
Authors(AuthorId, Name, Nick)
Primary Key AuthorId
Alternate Key Nick
Archive(Num, Year, Month)
Primary Key Num
Alternate Key Year, Month
GameRubric(GrubricId, GRubric)
Primary Key GrubricId
Alternate Key GRubric
JournalRubric(JrubricId, JRubric)
Primary Key JrubricId
Alternate Key Jrubric
Demoversions(NameId, Size, Links, Comment, UploadTime)
Primary Key NameId
Alternate Key Links
Trainers(NameId, Version, Comment, FileName, UploadTime)
Primary Key NameId
Alternate Key FileName
Patches(NameId, Version, Comment, PublishTime, UploadTime, Links)
Primary Key NameId
Alternate Key Links
Wallpapers(NameId, UploadTime, PicDir)
Primary Key NameId
Alternate Key PicDir
Videorollicks(NameId, Size, Links, Comment, UploadTime)
Primary Key NameId
Alternate Key Links
Слабые типы сущностей.
Для каждой слабой сущности, присутствующей в логической модели, создается отношение, включающее все простые атрибуты этой сущности. Дополнительно в отношение включается атрибут внешнего ключа, соответствующего первичному ключу сущности-влдельца. Первичный ключ слабой сущности частично или полностью выводиться из ключа сущности-владельца.
GameArticle(NameId, GameId, Num, GrubricId, PubPlace, UploadTime)
Primary Key NameId
Alternate Key GameId, Num, GrubricId, PubPlace
Foreign Key GameId references Game(GameId)
Foreign Key Num references Archive(Num)
Foreign Key GrubricId references GameRubric(GrubricId)
NonGameArticle(NameId, Num, JrubricId, ArtName, UploadTime)
Primary Key NameId
Alternate Key Num, JrubricId, ArtName
Foreign Key Num references Archive(Num)
Foreign Key JrubricId references JournalRubric
Writing(GameId)
Foreign Key GameId references Game(GameId)
Work_GA(AuthorId)
Foreign Key AuthorId references Authors(AuthorId)
Work_NGA(AuthorId)
Foreign Key AuthorId references Authors(AuthorId)
Бинарные связи типа «один ко многим» (1:М)
Для каждой бинарной связи типа 1:М, установленной в логической модели данных между сущностями E1 и E2, необходимо переслать копию атрибутов первичного ключа сущности Е1 в отношение, представляющее сущность Е2, где они будут играть роль внешнего ключа. Сущность, представляющая «единичную» сторону связи определяется как родительская, а сущность, представляющая «множественную» сторону, - как дочерняя. Следовательно:
Demoversions(NameId, GameId, Size, Links, Comment, UploadTime)
Primary Key NameId
Alternate Key Links
Foreign Key GameId references Game(GameId)
Trainers(NameId, GameId, Version, Comment, FileName, UploadTime)
Primary Key NameId
Alternate Key FileName
Foreign Key GameId references Game(GameId)
Patches(NameId, GameId, Version, Comment, PublishTime, UploadTime, Links)
Primary Key NameId
Alternate Key Links
Foreign Key GameId references Game(GameId)
Wallpapers(NameId, GameId, UploadTime, PicDir)
Primary Key NameId
Alternate Key PicDir
Foreign Key GameId references Game(GameId)
Videorollicks(NameId, GameId, Size, Links, Comment, UploadTime)
Primary Key NameId
Alternate Key Links
Foreign Key GameId references Game(GameId)
Writing(GameId, NameId)
Primary Key NgameId, NameId
Foreign Key GameId references Game(GameId)
Foreign Key NameId references NonGameArticle(NameId)
Work_GA(AuthorId,NameId)
Primary Key AuthorId, NameId
Foreign Key AuthorId references Authors(AuthorId)
Foreign Key NameId references GameArticle(NameId)
Work_NGA(AuthorId,NameId)
Primary Key AuthorId, NameId
Foreign Key AuthorId references Authors(AuthorId)
Foreign Key NameId references NonGameArticle(NameId)
Сущности Demoversions, Trainers, Patches, Wallpapers и Videorollicks должны были бы также унаследовать в свои внешние ключи атрибут из сущности GameRubric. Однако, вследствие того, что каждую из этих сущностей целиком однозначно определяет одна и только одна запись из GameRubric, необходимость использования этого ключа отпадает.
Документирование созданных отношений и атрибутов внешних ключей.
Этап 2.3 Проверка модели с помощью правил нормализации
На этом этапе необходимо проверить созданный набор отношений на соответствие всем требованиям процедуры нормализации. Полный процесс нормализации отношений включает следующие действия:
§ приведение к первой нормальной форме (1НФ), позволяющие удалить из отношений повторяющиеся группы атрибутов;
§ приведение ко второй нормальной форме (2НФ), позволяющее устранить частичную зависимость атрибутов от первичного ключа;
§ приведение к третьей нормальной форме (3НФ), позволяющее устранить транзитивную зависимость атрибутов от первичного ключа;
§ приведение к нормальной форме Бойса-Кодда (НФБК), позволяющее удалить из функциональных зависимостей оставшиеся аномалии.
Чтобы убедиться, что каждое из отношений, описанных в приложении 3, находится, как минимум в нормальной форме Бойса-Кодда (НБФК), мы проанализируем функциональные зависимости между отношениями. Если будет обнаружено отношение, которое не представлено в НБФК, это может означать, что созданная логическая модель структурно неверна, либо при определении на её основе полного набора отношений была допущена ошибка. В любом случае, потребуется вернуться к предыдущему этапу и внести необходимые изменения.
Подобные документы
Разработка и программная реализация сайта и базы данных, наполнение базы данных тестовой информацией о товарах. Инструментальные средства создания сайта. Организация тестирования сайта, модуль визуализации интерфейса. Создание запросов в базе данных 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
