СОДЕРЖАНИЕ 
 

Введение           3

1. Организация  баз данных        4

1.1 Этап концептуального проектирования     4

1.2 Этап логического проектирования      7

1.3 Этап физического проектирования      8

2. Физическая  организация баз данных      10

2.1 Этап физического проектирования базы данных   10

2.2 Создание таблиц         14

2.3 Использование полей подстановок при создании таблиц  20

2.4 Установка связей между таблицами     24

2.5 Макет таблицы         27

2.6 Импорт и присоединение внешних таблиц    28

Заключение          29

Литература           30

Приложения 

 

ВВЕДЕНИЕ 

     Автоматизированная информационная система – это комплекс программных и технических средств, обеспечивающих сбор, обработку и манипулирование данными.

     Цель  любой информационной системы – обработка данных об объектах реального мира. Основой информационной системы является база данных. В широком смысле слова база данных – это совокупность сведений о конкретных объектах реального мира в каком-либо ПО. В узком смысле база данных – это поименованная, определённым образом организованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой ПО.

     Под ПО принято понимать часть реального  мира, подлежащего изучению для организации  управления.

     Объектом  называют элемент ПО, информация о котором интересует пользователя. Каждый объект описывается рядом основных свойств – атрибутов. Атрибутом называют поименованную характеристику объекта. Он показывает, какая информация об объекте интересует пользователя и должна храниться в базе данных. Например, ПО – высшее учебное заведение; объекты – студент, преподаватель; атрибуты – фамилия студента, его адрес проживания, группа, фамилия преподавателя, дисциплина, которую он читает, учёное звание и учёная степень.

     Процесс проектирования баз данных состоит из трёх этапов: концептуального, логического и физического проектирования. Результат каждого этапа – соответствующая модель ПО, что отражает трёхуровневую архитектуру (концептуальный, внешний, внутренний уровни) любой автоматизированной информационной системы.

     Задачей курсового проекта ставилось  рассмотреть один из этапов проектирования баз данных, так как данных уровень  является одним из наиболее важных при проектировании.

 

1. ОРГАНИЗАЦИЯ БАЗ ДАННЫХ

      1.1 Этап концептуального проектирования

     Концептуальное проектирование начинается с анализа ПО, включает анализ концептуальных требований и информационных потребностей, выявление информационных объектов (ИО) и связей между ними, построение концептуальной модели (схемы) данных.

     Объединение частных представлений о содержимом БД, полученных в результате опроса пользователей, позволяет создать обобщённое неформальное описание создаваемой БД. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных проектировщикам ИС, называют концептуальной (инфологической) моделью данных.

     Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их атрибуты  (свойства).

Сущность (информационный объект) (ИО) – любой конкретный (реальный) или абстрактный объект в рассматриваемой ПО.

     Связь – наблюдаемая взаимосвязь (ассоциация) между сущностями.

     Для представления концептуальной модели используют различные методы и модели, например, модель “сущность” – “атрибут” – “связь” (EAR) описывает ПО на концептуальном уровне в виде EAR-диаграмм. В них сущности помечаются прямоугольниками, ассоциации (характеры объединения сущностей) – ромбами или шестиугольниками, атрибуты – овалами, а связи между ними – рёбрами, над которыми проставляются типы связей.

     Между сущностями возможны четыре типа связей: один – к одному (1 « 1), один – ко многим (1 « ¥), многие – к одному (¥ « 1), многие – ко многим (¥ « ¥).

     Связь 1 « 1: в любой момент времени каждому экземпляру первого ИО соответствует 1 или 0 экземпляров другого ИО и наоборот.

     Связь 1 « ¥: одному экземпляру первого ИО соответствует 0,1,2,… экземпляров другого и наоборот, каждому экземпляру второго ИО соответствует 0 или 1 экземпляр первого ИО. Аналогично определяется тип связи  ¥ « 1.

     Связь ¥ « ¥: одному экземпляру первого ИО соответствует 0,1,2,… экземпляров другого ИО и наоборот.

      Примеры:

1. Студент 1 « 1 Сессия: каждый студент имеет определённый набор экзаменационных оценок в сессию. Имеется в виду ИО Сессия как набор оценок за текущий семестр.
2. Стипендия 1 « ¥ Студент: вид (и сумма) стипендии может многократно повторяться для различных студентов по результатам сессии.
3. Студент ¥ « ¥ Преподаватель: один студент обучается у многих преподавателей и наоборот, один преподаватель обучает многих студентов.

      Концептуальная  модель применяется для структурирования ПО с учётом информационных интересов  пользователей ИС, она не зависит  ни от программных, ни от технических  решений.

      Рассмотрим  пример: проектирование БД ИС “Бухгалтерский учёт на предприятии”. Фрагмент концептуальной модели, соответствующей подсистеме “Расчёты с контрагентами” в виде EAR-диаграмм “сущность” – “атрибут” – “связь”, представлен в приложении 1. В результате анализа ПО выделено четыре ИО (План счетов, Контрагенты, Валюты, Журнал хозяйственных операций (ЖХО)), их свойства и связи.

      Определим связи между сущностями: 

      Итак, концептуальная модель – это описание ПО, включающее совокупность информационных объектов, их атрибутов и взаимосвязей, выявленных в результате анализа.

      1.2 Этап логического проектирования

     Основной задачей логического проектирования является разработка логической схемы (модели), ориентированной на выбранную систему управления  базами данных (СУБД).

     СУБД – это комплекс программных и языковых средств, предназначенных для создания, ведения и совместного применения БД любыми пользователями [1, с. 107].

     СУБД  осуществляет централизованное управление базой данных, обеспечивает доступ к данным, по сути, выступает в  качестве интерфейса между пользователями и БД.

     Одним из основных критериев выбора СУБД является оценка того, насколько эффективно внутренняя модель данных, поддерживаемая системой, способна описать концептуальную схему ПО. Существующие СУБД делятся по типам моделей данных на реляционные, иерархические и сетевые.

     Модель данных (МД) – формально определённая структура, которая используется для представления данных. Иерархическая МД организует данные в виде древовидной структуры, сетевая – в виде сетевой, реляционная МД – в виде таблиц (отношений).

     Процесс логического проектирования состоит из следующих действий:

• выбор конкретной СУБД;
• отображение концептуальной схемы на логическую схему, получение логической МД, соответствующей внешнему уровню архитектуры любой автоматизированной ИС;
• выбор ключей;
• описание языка запросов.

     При отображении концептуальной МД ПО на реляционную МД каждый прямоугольник схемы (рис. 1) – информационный объект преобразуется  в таблицу (отношение).

     Теория  конструирования реляционных БД разработана доктором Е.Ф. Коддом в 1968 г. Сформулированные им 13 правил [2] полностью реализованы в реляционной СУБД MS Access. Им же введены основные понятия реляционной БД, которыми являются: “тип данных”, “домен”, “атрибут”, “кортеж”, “первичный ключ”, “отношение”.

     Понятие “тип данных” в реляционной МД полностью адекватно понятию типа данных в языках программирования.

Рассмотрим  отношение “План счетов” (рис. 2). 

  
 

 

Рис. 2. Отношение  “План счетов” 

     Домен определяется как допустимое потенциальное множество значений данного (стандартного) типа. Например, для домена “название счёта” допустимость означает, что множество значений – только те, которые представлены в плане счетов – документе как названия счетов.

     Схема отношения – это именованное множество пар {имя атрибута, имя домена}. Степень или “арность” схемы отношения – мощность этого множества. Степень отношения “План счетов” равна 5.

     Кортеж, соответствующий данной схеме отношения, – это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения, а “значение” – допустимое значение домена данного атрибута.

     Отношение – это множество кортежей, соответствующих одной схеме.

     В литературе часто используют неформальную терминологию реляционных баз данных: отношение – таблица, кортеж – строка, домен – столбец.

     Доктор  Е.Ф. Кодд ввёл понятия реляционной алгебры (РА) и реляционного исчисления (РИ) [2].

     РА – совокупность множества отношений и множества операций над ними. С точки зрения обработки информации РА является процедурным языком обработки реляционных таблиц, обеспечивающим пошаговое решение задач. РИ – непроцедурный язык, позволяющий формулировать, что нужно сделать, а не как. Например, в РИ запрос создаётся путём определения таблицы (бланка) запроса за один шаг. Е.Ф. Кодд показал, что понятия РА и РИ логически эквивалентны, что чрезвычайно важно. Это означает, что любой запрос, который можно сформулировать при помощи РИ, также можно сформулировать, пользуясь РА, и наоборот.