Концептуальное проектирование БД

КОНСПЕКТ ОБЗОРНОЙ ЛЕКЦИИ

Для студентов специальности
Т1002 «Программное обеспечение информационных технологий»

(Л.В. Рудикова, к.ф.-м.н., доцент)

Вопрос 31. АРХИТЕКТУРА СУБД. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ

1. Понятие базы данных.

2. Трехуровневая архитектура базы данных.

3. Жизненный цикл базы данных.

4. Архитектура СУБД.

5. Реляционная модель данных.

6. Проектирование реляционных баз данных.

7. Нормальные формы отношений.

8. Реляционная алгебра.

1. Понятие базы данных.

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

Информационная система – автоматическая система, организующая данные и выдающая информацию.

Информационно-управляющая система – система, обеспечивающая информационную поддержку менеджмента.

Данные – разрозненные факты.

Информация – организованные и обработанные данные.

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

Каждая СУБД должна удовлетворять следующим требованиям:

· обеспечивать пользователю возможность создавать новые БД и определять их схему (логическую структуру данных) с помощью специального языка - языка определения данных ; поддерживать разнообразные представления одних и тех же данных;

· позволять «запрашивать » данные и изменять их с помощью языка запросов , или языка манипулирования данными ; допускать интеграцию и совместное использование данных различными приложениями;

· поддерживать хранение очень больших массивов данных, измеряемых гигабайтами и более, в течение долгого времени, защищая их от случайной порчи и неавторизованного использования, а также - обеспечивать модификацию БД и доступ к данным путем запросов, т.е. гарантировать безопасность и целостность данных;

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

Система с базой данных состоит из следующих компонентов:

· Пользователи, т.е. люди, которые используют данные.

· Приложения, т.е. программы пользователей, которым требуются данные из системы.

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

· Данные, т.е. строки, хранящиеся в файлах.

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

Таким образом, систему с БД можно представить в виде следующей последовательности уровней:

На самом нижнем уровне находятся данные, хранящиеся в физических файлах (физическая память БД). На верхнем уровне – приложений с их собственными представлениями одних и тех же физических данных. Каждой представление БД – это определенная логическая структура, построенная из лежащих в основе физических данных. Чтобы обеспечить интерфейс между физической памятью БД и ее разнообразными логическими версиями (множеством поддерживаемых представлений) СУБД, в свою очередь должна состоять из нескольких уровней.

2. Трехуровневая архитектура базы данных.

Различие между логическим и физическим представлением данных официально признано в 1978 году, когда комитет ANSI / SPARC предложил обобщенную структуру систем баз данных. Эта структура получила название трехуровневой архитектуры. Три уровня архитектуры следующие: внутренний, концептуальный и внешний.

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

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

Внешний уровень – структурный уровень БД, определяющий пользовательские представления данных. Каждая пользовательская группа получает свое собственное представление данных в БД. Каждое такое представление данных дает ориентированное на пользователя описание элементов данных, из которых состоит представление данных, и отношений между ними. Его можно напрямую вывести из концептуальной схемы. Совокупность таких пользовательских представлений данных и дает внешний уровень.

Представления пользователей и приложений	Внешний уровень
Отображения
Концептуальная схема	Концептуальный уровень
Отображение	Внутренний уровень
Система-хост
Хранящиеся данные

Рис. Уровни СУБД

3. Жизненный цикл базы данных.

Процесс проектирования, реализации иподдержания системы базы данных называется жизненным циклом базы данных (ЖЦБД). Процедура создания системы называется жизненным циклом системы (ЖЦС).

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

ЖЦБД состоит из следующих этапов:

1. Предварительное планирование – планирование БД, выполняемое в процессе разработки стратегического плана БД. В процессе планирования собирается следующая информация:

· какие прикладные программы используются, и какие функции они выполняют;

· какие файлы связаны с каждым из этих приложений;

· какие новые приложения и файлы находятся в процессе работы.

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

Информация этого этапа документируется в виде обобщенной модели данных.

2. Проверка осуществимости . Здесь определяется технологическая, операционная и экономическая осуществимость плана создания БД, т. е.:

· технологическая осуществимость – есть ли технология для реализации запланированной БД?

· операционная осуществимость – есть ли средства и эксперты, необходимые для успешного осуществления плана создания БД?

· экономическая целесообразность – можно ли определить выводы? Окупится ли запланированная система? Можно ли оценить издержки и выгоду?

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

· Определяются цели системы путём анализа информационных потребностей. Здесь также обязательно указывается, какую именно БД следует создавать (распределённую, целостную) и какие коммуникационные средства необходимы. Выходной документ – комментарий, описывающий цели системы.

· Определение пользовательских требований: документация в виде обобщённой информации (комментарии, отчёты, опросы, анкеты и т. д.); фиксация функций системы и определение прикладных систем, которые будут выполнять эти требования. Данные представляются в виде соответствующих документов.

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

· Разработка плана поэтапного создания системы, включающий выбор исходных приложений.

4. Концептуальное проектирование – создание концептуальной схемы БД. Спецификации разрабатываются в той степени, которая необходима для перехода к реализации.

Основным выходным документом является единая инфологическая модель (или схема БД на концептуальном уровне ). При разработке данной модели используются информация и функции, которые должна выполнить система, определённые на этапе сбора и определения требований к системе. На данном этапе желательно также определить: 1) правила для данных; 2) правила для процессов; 3) правила для интерфейса.

5. Реализация – процесс превращения концептуальной модели в функциональную БД. Он включает в себя следующие этапы.

1) Выбор и приобретение необходимой СУБД.

2) Преобразование концептуальной (инфологической) модели БД в логическую и физическую модель данных:

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

· определяются, какие прикладные процессы необходимо реализовать в схеме данных как хранимые процедуры;

· реализовать ограничения, предназначенные для обеспечения целостности данных и реализации правил для данных;

· спроектировать и сгенерировать триггеры для реализации всех централизованно определённых правил для данных и правил целостности данных, которые не могут быть заданы как ограничения;

· разработать стратегию индексирования и кластеризации; выполнить оценку размеров всех таблиц, кластеров и индексов;

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

· разработать сетевую топологию БД и механизм бесшовного доступа к удалённым данным (реплицированная или распределённая БД).

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

4) Заполнение базы данных.

5) Создание прикладных программ, контроль управления.

6) Обучение пользователей.

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

Таким образом, ЖЦБД включает в себя:

· Изучение предметной области и представление соответствующей документации (1-3).

· Построение инфологической модели (4).

· Реализация (5).

· Оценка работы и поддержка БД (6).

4. Архитектура СУБД.

Рис. Главные компоненты СУБД

Данные, метаданные - содержат не только данные, но и информацию о структуре данных (метаданные ). В реляционной СУБД метаданные включают в себя системные таблицы (отношения), имена отношений, имена атрибутов этих отношений и типы данных этих атрибутов.

Часто СУБД поддерживает индексы данных. Индекс - это структура данных, которая помогает быстро найти элементы данных при наличии части их значения (например, индекс, который находит кортежи конкретного отношения, имеющие заданное значение одного из атрибутов). Индексы - часть хранимых данных, а описания, указывающие, какие атрибуты имеют индексы - часть метаданных.

Менеджер памяти -получает требуемую информацию из места хранения данных и изменяет в нем информацию по требованию расположенных выше уровней системы.

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

· Менеджер файлов контролирует расположение файлов на диске и получает блок или блоки, содержащие файлы, по запросу менеджера буфера (диск в общем случае делится на дисковые блоки - смежные области памяти, содержащие от 4000 до 16000 байт).

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

Процессор «запроса» - обрабатывает запросы и запрашивает изменения данных или метаданных. Он предлагает лучший способ выполнения необходимой операции и выдает соответствующие команды менеджеру памяти.

Процессор (менеджер) запросов превращает запрос или действие с БД, которые могут быть выполнены на очень высоком уровне (например, в виде запроса SQL ), в последовательность запросов на хранимые данные типа отдельных кортежей отношения или частей индекса на отношении. Часто самой трудной частью обработки запроса является его организация , т. е. выбор хорошего плана запроса или последовательности запросов к системе памяти, отвечающей на запрос.

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

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

Как правило, система БД поддерживает одновременно множество транзакций. Именно правильное выполнение всех таких транзакций и обеспечивает менеджер транзакций . Правильное выполнение транзакций обеспечивается ACID -свойствами (atomicity , consistency , isolation , durability ):

· атомарность - выполнение либо всех транзакций, либо ни одной из них (например, изъятие денег из банкомата и внесение соответственного дебета в счет клиента должны быть единственной атомарной транзакцией, не допускается выполнение каждой из этих операций по отдельности);

· непротиворечивость - состояние, при котором данные соответствуют всем возможным ожиданиям (например, условие непротиворечивости для БД авиационных линий состоит в том, что ни одно из мест в самолете не бронируется для двух пассажиров);

· изоляция - при параллельном выполнении двух или более транзакций их результаты должны быть изолированы друг от друга. Одновременное выполнение двух транзакций одновременно не должно привести к результату, которого не было бы, если они выполнялись последовательно (например, при продаже билетов на один и тот же рейс в случае свободного последнего места при одновременном запросе двух агентов, запрос одного должен быть выполнен, другого - нет);

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

Рассмотрим также 3 типа обращения к СУБД:

1. Запросы - вопросы по поводу данных могут генерироваться двумя способами:

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

б) с помощью интерфейсов прикладных программ - запросы передаются через специальный интерфейс (через этот интерфейс нельзя передавать произвольные запросы);

2. Модификации - это операции по изменению данных. Они также могут выполняться либо с помощью общего интерфейса, либо через интерфейс прикладной программы;

3. Модификации схемы - это команды администраторов БД, которые имеют право изменять схему БД или создавать новую БД.

Архитектура клиент/сервер. Во многих вариантах современного ПО реализуется архитектура клиент/сервер : один процесс (клиент) посылает запрос для выполнения другому процессу (серверу). Как правило, БД часто разделяется на процесс сервера и несколько процессов клиента.

В простейшей архитектуре клиент/сервер вся СУБД является сервером, за исключением интерфейсов запроса, которые взаимодействуют с пользователем и посылают запросы или другие команды на сервер. Например, реляционная СУБД часто использует язык SQL для представления запросов от клиента к серверу. Затем сервер БД предоставляет клиенту ответ в виде таблицы (отношения). Существует тенденция увеличения нагрузки на клиента, т. к. при наличии множества одновременно работающих пользователей БД с сервером могут возникнуть проблемы.

5. Реляционная модель данных.

РМД некоторой предметной области представляет собой набор отношений, изменяющихся во времени. При создании информационной системы совокупность отношений позволяет хранить данные об объектах предметной области и моделировать связи между ними.

Отношение представляет собой двумерную таблицу, содержащую некоторые данные. Математически под N -арным отношением R понимают множество декартова произведения D 1 D 2 … D n множеств (доменов ) D 1, D 2 , …, D n (), необязательно различных:

R D 1 D 2 … D n ,

где D 1 D 2 … D n – полное декартово произведение, т.е. набор всевозможных сочетаний из n элементов каждое, где каждый элемент берется их своего домена.

Домен - это семантическое понятие. Домен можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами:

· Домен имеет уникальное имя (в пределах базы данных).

· Домен определен на некотором простом типе данных или на другом домене.

· Домен может иметь некоторое логическое условие , позволяющее описать подмножество данных, допустимых для данного домена.

· Домен несет определенную смысловую нагрузку .

Атрибут отношения есть пара вида <Имя_атрибута: Имя_домена>. Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов.

Отношение R , определенное на множестве доменов, содержит две части: заголовок и тело.

Заголовок отношения – это фиксированное количество атрибутов отношения:

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

Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида <Имя_атрибута: Значение_атрибута>:

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

Отношение обычно записывается в виде:

или короче

,

или просто

Число атрибутов в отношении называют степенью (или -арностью ) отношения. Мощность множества кортежей отношения называют мощностью отношения.

Схемой отношения называется перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:

Если атрибуты принимают значения из одного и того же домена, то они называются -сравнимыми, где – множество допустимых операций сравнений, заданных для данного домена. Например, если домен содержит числовые данные, то для него допустимы все операции сравнения, тогда . Однако, и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он имеет также полный спектр операций сравнения.

Схемы двух отношений называются эквивалентными , если они имеют одинаковую степень и возможно такое упорядочение имен атрибутов в схемах, что на одинаковых местах будут находиться сравнимые атрибуты, то есть атрибуты, принимающие значения из одного домена:

Пусть – схема отношения . – схема отношения после упорядочения имен атрибутов. Тогда

~

Таким образом, для эквивалентных отношений выполняются следующие условия:

· Таблицы имеют одинаковое количество столбцов.

· Таблицы содержат столбцы с одинаковыми наименованиями.

· Столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов.

· Таблицы имеют одинаковые строки с учетом того, что порядок столбцов может различаться.

Все такие таблицы есть различные изображения одного и того же отношения.

Свойства отношений. Свойства отношений непосредственно следуют из приведенного выше определения отношения. В этих свойствах в основном и состоят различия между отношениями и таблицами.

· В отношении нет одинаковых кортежей .

· Кортежи не упорядочены (сверху вниз) .

· Атрибуты не упорядочены (слева направо) .

· Все значения атрибутов атомарны .

Рис. Схематическое изображение отношения

Реляционная модель представляет собой базу данных в виде множества взаимосвязанных отношений. В каждой связи одно отношение может выступать как основное, а другое отношение выступает в роли подчиненного. Таким образом, один кортеж основного отношения может быть связан с несколькими кортежами подчиненного отношения. Для поддержки этих связей оба отношения должны содержать наборы атрибутов, по которым они связаны. В основном отношении это первичный ключ отношения , который однозначно определяет кортеж основного отношения. В подчиненном отношении для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу основного отношения. Однако здесь этот набор атрибутов уже является вторичным ключом или внешним ключом , т.е. он определяет множество кортежей отношения, которые связаны с единственным кортежем основного отношения.

6. Проектирование реляционных баз данных.

При проектирование реляционной БД должны быть решены следующие проблемы:

1) С учетом семантики предметной области необходимо наилучшим способом представить объекты предметной области в виде абстрактной модели данных (даталогическое проектирование). Т.е. - определиться со схемой БД: из каких отношений должны состоять БД, какие атрибуты должны быть у этих отношений, каковы связи между отношениями.

2) Обеспечить эффективность выполнения запросов к базе данных (физическое проектирование БД).

После проведения этапа даталогического проектирования должны быть получены следующие результирующие документы:

· Построение корректной схемы данных ориентируясь на реляционную модель данных.

· Описание схемы БД в терминах выбранной СУБД.

· Описание внешних моделей в терминах выбранной СУБД.

· Описание декларативных правил поддержки целостности БД.

· Разработка процедур поддержки семантической целостности БД.

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

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

Проектирование схемы БД можно выполнить двумя методами:

· Метод декомпозиции (разбиения) – исходное множество отношений, входящих в схему БД заменяется другим множеством отношений, являющихся проекциями исходных отношений! При этом число отношений возрастает.

· Метод синтеза – компоновка схемы БД из заданных исходных элементарных зависимостей между объектами предметной области.

Классическое проектирование БД связано с теорией нормализацией , которая основана на анализе функциональных зависимостей между атрибутами отношений. Функциональные зависимости определяют устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области.

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

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

В теории реляционных БД обычно выделяют следующие нормальные формы:

первая нормальная форма (1 NF );

· вторая нормальная форма (2 NF );

· третья нормальная форма (3 NF );

· нормальная форма Байса-Кодда (BCNF );

· четвертая нормальная форма (4 NF );

· пятая нормальная форма или форма проекции - соединения (5 NF или PYNF ).

Основные свойства нормальных форм:

· каждая следующая нормальная форма в некотором смысле лучше предыдущей;

· при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

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

7. Нормальные формы отношений.

В основе процесса нормализации лежит адекватное отражение предметной области в виде таблиц, содержащих данные о моделируемом объекте, и возможность изменения состояния базы данных с течением времени. Как правило, из-за несоответствия модели данных предметной области могут возникнуть аномалии, которые проявляются при выполнении соответствующих операций:

· Аномалии вставки (INSERT) – хранение в одном отношении разнородной информации.

· Аномалии обновления (UPDATE) –избыточность данных отношения из-за хранения разнородной.

· Аномалии удаления (DELETE) – хранение разнородной информации в одном отношении.

Следует учитывать также возникающие неопределенные ( NULL ) значения . В разных СУБД при выполнении различных операций (сравнение, объединение, сортировка, группировка и др.) два NULL -значения могут быть или не быть равными друг другу, по разному влиять на результат выполнения операций по определению средних значений и нахождения количества значений. Для исключения ошибок во многих СУБД существует возможность замены NULL -значения нулем при выполнении расчетов, объявление всех NULL -значений равными друг другу и т.п.

Нормализация – разбиение таблицы на несколько, которые обладают лучшими свойствами при обновлении, вставке и удалении данных. Т.е. нормализация представляет собой процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ, однако, на практике достаточно привести таблицы к НФБК.

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

Если заменить на время нормализации коды первичных (внешних) ключей, то следует рассмотреть 2 случая:

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

Заменить , первичный ключ , ФЗ

на , первичный ключ

и , первичный ключ .

2. Таблица имеет первичный (возможный) ключ , поле , которое не является возможным ключом, но функционально зависит от , а также – другое неключевое поле , функционально зависящее от : . Рекомендуется сформировать таблицу содержащую и ( - первичный ключ), и – удалить из первоначальной таблицы: Следует заметить, что для проведения таких операций первоначально следует иметь, в качестве входных данных некоторые «большие» (универсальные) отношения.

Опр.1. Отношение находится в первой нормальной форме (1НФ) тогда и только тогда, когда ни одна из его строк не содержит в любом своем поле одного значения и ни одного из ключевых полей отношения не пусто.

По опр.1, любое отношение будет находиться в 1НФ, т.е. отношение, удовлетворяющее свойствам отношений: в отношении нет одинаковых кортежей; кортежи не упорядочены; атрибуты не упорядочены и различаются по наименованию; все значения атрибутов атомарны.

Опр.2. Отношение находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от части сложного ключа (т.е. все поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом).

Если потенциальный ключ является простым, то отношение автоматически находится в 2НФ.

Чтобы устранить зависимость атрибутов от части сложного ключа, необходимо произвести декомпозицию отношения на несколько отношений. Атрибуты, которые зависят от части сложного ключа, выносятся в отдельное отношение.

Атрибуты отношения называются взаимно-независимыми , если ни один из них не является функционально зависимым от другого.

Опр.3. Отношение находится в третьей нормальной форме (3НФ) тогда и только тогда, когда отношение находятся в 2НФ и все неключевые атрибуты взаимно независимы (т.е. ни одно из неключевые полей отношения не зависит функционально от любого другого неключевого поля).

Чтобы устранить зависимость неключевых атрибутов, нужно произвести декомпозицию отношения на несколько отношений. При этом те неключевые атрибуты, которые являются зависимыми, выносятся в отдельное отношение.

При приведении отношений при помощи алгоритма нормализации к отношениям в 3НФ предполагается, что все отношения содержат один потенциальный ключ. Это не всегда верно. Бывают случаи, когда отношение может содержать несколько ключей.

Опр.4. Отношение находится в нормальной форме Байса-Кодда (НФБК) тогда и только тогда, когда детерминанты всех функциональных зависимостей являются потенциальными ключами (либо - если любая функциональная зависимость между его палями сводится к полной функциональной зависимости от возможного ключа).

Если отношение находится в НФБК, то оно автоматически находится в 3НФ, что следует из определения 4. Чтобы устранить зависимость от детерминантов, не являющихся потенциальными ключами, следует провести декомпозицию, вынося эти детерминанты и зависимые от них части в отдельное отношение.

Бывают случаи, когда отношение не содержит никаких функциональных зависимостей. Т.е. отношение является полностью ключевым, т.е. ключом отношения является все множество атрибутов. Т.о., мы имеем многозначную зависимость, т.к. взаимосвязь между атрибутами все-таки имеется.

Опр.5. Отношение находится в четвертой нормальной форме (4НФ) тогда и только тогда, когда отношение находится в НФБК и не содержит нетривиальных многозначных зависимостей.

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

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

Опр.6. Отношение находится в пятой нормальной форме (5НФ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной.

Опр.6. тождественно также следует определению.

Опр.7. Отношение не находится в 5НФ, если в отношении найдется нетривиальная зависимость соединения.

Т.о. если в каждой полной декомпозиции все проекции исходного отношения содержат возможный ключ, можно сделать вывод о том, что отношение находится в 5НФ. Отношение, не имеющее ни одной полной декомпозиции также находится в 5НФ.

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

Возможным ключом отношения называется набор атрибутов отношения, который полностью и однозначно (функционально полно) определит значения всех остальных атрибутов отношения. В общем случае в отношении может быть несколько возможных ключей. Среди всех возможных ключей отношения как правило выбирают один, который считается главным и который называют первичным ключом отношения.

Взаимно-независимые атрибуты – это атрибуты, не зависящие один от другого. Если в отношение существует несколько ФЗ, то каждый атрибут или набор атрибутов, от которого зависит другой атрибут, называется детерминантом отношения.

9. Реляционная алгебра.

Реляционная алгебра представляет собой основу доступа к реляционным данным. Основная цель алгебры – обеспечить запись выражений. Выражения могут использоваться для:

· определения области выборки , т.е. определения данных для их выбора, как результата операции выборки;

· определения области обновления , т.е. определения данных для их вставки, изменения или удаления, как результата операции обновления;

· определение (именованных) виртуальных отношений , т.е. представление данных для их визуализации через представления;

· определение снимка, т.е. определение данных для сохранения в виде «мгновенного снимка» отношения;

· определение правил безопасности, т.е. определение данных, для которых осуществляется контроль доступа;

· определение требований устойчивости, т.е. определение данных, которые входят в область для некоторых операций управления одновременным доступом;

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

В реализациях конкретных реляционных СУБД сейчас не используется в чистом виде ни реляционная алгебра, ни реляционное исчисление. Фактическим стандартом доступа к реляционным данным стал язык SQL (Structured Query Language).

Реляционная алгебра, определенная Коддом состоит из 8 операторов, составляющих 2 группы:

• традиционные операции над множествами (объединение, пересечение, вычитание, декартово произведение);
• специальные реляционные операции (выборка, проекция, соединение, деление).

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

Краткий обзор операторов реляционной алгебры.

Выборка – возвращает отношение, которое содержит все кортежи определенного отношения, удовлетворяющие некоторым условиям. Операция выборки называется также операцией ограничения (restrict - ограничение, сейчас чаще принимается выборка - SELECT ).

Проекция – возвращает отношение, содержащее все кортежи (т.е. - под кортежи) определенного отношения после исключения из него некоторых атрибутов.

Произведение – возвращает отношение, содержащее всевозможные кортежи, которые являются сочетанием двух кортежей, принадлежащих соответственно двум определенным отношениям.

Объединение – возвращает отношение, содержащее все кортежи, которые принадлежат или одному из двух определенных отношений, или обоим.

Пересечение – возвращает отношение, содержащее все кортежи, которые принадлежат одновременно двум определенным отношениям.

Вычитание – возвращает отношение, содержащее все кортежи, которые принадлежат первому из двух определенных отношений и не принадлежат второму.

Соединение (естественное) – возвращает отношение, кортежи которого - это сочетание двух кортежей (принадлежащих соответственно двум определенным отношениям), имеющих общее значение для одного или нескольких общих атрибутов этих двух отношений (и такие общие значения в результирующем кортеже появляются только один раз, а не дважды).

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

ЛИТЕРАТУРА

1. Дейт К.Дж. Введение в системы баз данных, 6-е издание: Пер. с англ. – К.; М.; СПб.: Издательский дом «Вильямс», 2000. – 848 с.

2. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2000. – 1120 с.

3. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.

4. Фаронов В.В., Шумаков П.В. Delphi 4. Руководство разработчика баз данных. – М.: «Нолидж», 1999. – 560 с.

5. Дж. Грофф, П.Вайнберг. SQL: Полное руководство: Пер. с англ. – К.: Издательская группа BHV, 2001. – 816 с.

6. Кен Гетц, Пол Литвин, Майк Гилберт. Access 2000. Руководство разработчика. Т.1, 2. Пер. с англ. – К.: Издательская группа BHV, 2000. – 1264 с, 912 c.

7. Маклаков С.В BPwin и EPwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001. – 304 с.

8. Ульман Д., Уидом Д. Введение в системы баз данных / Пер. с англ. – М.: «Лори», 2000. – 374 с.

9. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. Проф. А.Д.Хомоненко. – Спб.: КОРОНА принт, 2000. – 416 с.

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

Здесь выполняется три функции:

1. определение типов сущностей предметной области

2. определение типов связей между сущностями

3. определение атрибутов и связывание их с типами сущностей и связей.

4. создание локальных концептуальных моделей данных в виде диаграмм “сущность - связь”.

5. обсуждение ЛКИМД с пользователями.

Рис. 3.1.3.1 Соответствие этапов проектирования и элементов архитектуры ANSI/SPARC.

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

Логическое проектирование – это конструирование информационных моделей на базе существующих концептуальных модулей. Т.е. на этом этапе концептуальная модель данных преобразовывается в локальную логическую модель данных и далее в глобальную логическую модель данных(ГЛМД) с учетом типа используемой СУБД. Этот этап содержит 2 подэтапа:

На первом подэтапе выполняется:

1. преобразование локальной концептуальной модели данных (ЛКМД) в локальную логическую модель данных(ЛЛМД);

2. определение набора отношений(таблиц) исходя из структуры ЛЛМД;

3. проверка ЛЛМД с помощью правил нормализации;

4. проверка ЛЛМД в отношении транзакции пользователей;

5. создание окончательной диаграммы «сущность-связь» для каждой ЛЛМД;

6. определение требований к ЛЛМД с точки зрения обеспечения целостности данных;

7. обсуждение ЛЛМД с конечными пользователями.

На втором подэтапе выполняется:

1. слияние ЛЛМД в ГЛМД;

2. проверка и корректировка ГЛМД;

3. создание окончательного варианта диаграммы «сущность-связь», отображающей ГЛМД;

4. обсуждение ГЛМД с конечными пользователями.

Т.о. концептуальное и логическое проектирование позволяет решить следующие задачи:

1 - разбить весь проекта на группу относительно небольших простых задач исходя из структуры предметной области, т.е. создать ЛКМД

2 преобразовать ЛКМД в ЛЛМД

3 объединить ЛЛМД в ГЛМД

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

Этот этап состоит из 3-х подэтапов:

1. внедрение ГЛМД в среду конкретной СУБД:

Проектируются основные таблицы в среде СУБД

Реализация функций связанных с управлением ПО или т.н. бизнес-правил для ПО

2. создание проекта физического представления БД:

Выбор конкретной структуры хранения данных

Определение требований к внешней памяти

3. разработка средств защиты БД:

Разработка и учет пользовательских представлений о защите данных

Определение правил доступа для разных типов пользователей

На этом же этапе необходимо рассмотреть вопросы мониторинга и настройки всей системы.

Выбор СУБД.

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

Общий список параметров включает:

1. физические параметры:

предусмотрены ли файловые структуры в данной СУБД;

наличие средств индексирования;

наличие средств сжатия данных;

возможность шифрования данных;

требуемые объемы ОЗУ и ПЗУ для данной СУБД и т.д.

2. параметры определения данных:

тип базовой модели организации данных;

наличие поддержки в расширении первичных ключей;

наличие средств поддержки целостности данных;

предусмотренные типы данных;

3. общие параметры:

стоимость СУБД;

наличие поддержки работы СУБД в Internet;

производительность данной СУБД;

4. параметры, определяющие доступность в плане создания приложений:

возможности языка запросов;

наличие многопользовательского доступа;

возможность использования языков современного уровня;

5. группа параметров, описывающих средства технологии разработки ИС:

наличие инструментов для работы с оконным интерфейсом;

наличие case-инструментов;

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

Разработка приложений.

Цель разработки приложений заключается:

1. создание проекта транзакций

2. создание проекта интерфейса пользователя.

Проектирование транзакций.

Транзакций – одно действие или последовательность действий, выполняемых одним и тем же пользователем и/или одной прикладной программой(ПП), в результате чего появляется возможность обеспечить доступ к БД и/или изменить её содержимое (пример транзакций – регистрация клиента в БД какого-либо банка).

Обычно транзакция выполняется частично персоналом АИС, а частично ПП или самой СУБД.

Основные типы транзакций:

1. транзакции извлечения – действия, обозначающие выборку данных из базы

2. транзакции обновления – действия, в результате которых обеспечивается либо удаление определенных данных, либо их изменение, либо добавление некоторых данных.

3. смешанные транзакции

При проектировании транзакций необходимо определить и задокументировать характер(свойства) всех транзакций, которые будут реализовываться в АИС. В их числе:

1. исходные данные, которые использует транзакция;

2. выходные данные, формируемые транзакцией;

3. функциональные характеристики транзакций;

4. степень важности транзакции для пользователя;

5. предполагается интенсивность использования данной транзакции.

Предпосылкой создания своей методологии явился такой диагноз С.П.Никанорова существующему положению в развитии организаций: происходит накопление несистемных решений, повсеместно распространяется сиюминутное, ситуационное мышление, которое приводит к, так называемому, феномену складывания - процессу произвольного возникновения чего-то под действием многих факторов, которые проявляются стихийно. Если что-то неэффективно работает, то часто говорят: «Так сложилось, никто не виноват». Следствием складывания являются неконтролируемые области жизни и возникающие проблемы, которые требуют действий для их решения.
У кого возникают проблемы? Они могут быть только у субъектов, то есть у тех, кто имеет возможности и имеет интересы. Проблема для субъекта и состоит в несоответствии интересов возможностям. Субъекты могут приблизительно одинаково воспринимать то, что происходит, но они относят его к своим интересам и возможностям, которые не поднимаются выше определенного уровня. Поэтому то, что происходит, не воспринимается ими как единая цельная проблема, что и приводит к несистемным решениям.
Какие есть подходы к решению этих проблем? Некоторые субъекты надеются управиться с ними с помощью проблемно-ориентированного подхода, при котором исследуются выявленные недостатки, сдерживающие достижение субъектом его целей. Рафинированная форма этого подхода - системный анализ, который использует идеологию целенаправленных систем. Но устранить феномен складывания с помощью проблемно- ориентированных методов невозможно, так как возникают не отдельные проблемы, а клубок проблем. И если стараться решить какую-нибудь одну проблему, то клубок проблем только увеличивается и спутывается, как и обычный клубок ниток при вытягивании одной нити. Надо разрубить клубок с помощью нормативного подхода, который основан на полагании желаемого класса систем. При создании систем этот подход должен координироваться с проблемно-ориентированным подходом. Нелепо устранять недостатки изжитой системы. Надо не проблемы решать, а строить все заново, подчиняя этой идее и свои интересы, и свои возможности. Рафинированной формой нормативного подхода являются системы с идеалом, к которому они должны стремиться.
Недостатком этих подходов, возникших в 60-х годах 20-го столетия и являющихся продуктами гонки вооружений, является отсутствие представления о развитии, в частности, о переходе из устаревшего качества в новое качество, которое задается последовательностью целей.
В начале 1970-х годов, задолго до осознания широкими кругами разработчиков бесперспективности создания автоматизированных систем на базе традиционных методологий, С.П. Никаноров сформировал новый методологический подход, в котором объектом автоматизированного проектирования являлись не АСУ, а системы организационного управления (СОУ) . К этим системам отнесены любые организации, в которых осуществлялось производство, управление, проектирование, обучение и другие виды деятельности с использованием компьютерных информационных систем. Идея о необходимости и проблемах проектирования организаций рассмотрена в предисловии к переведенной под его редакцией книге С.Янга ( в разделе 1).
На основе этого подхода к 1978-му году был выпущен технический проект автоматизированной системы проектирования (АСП) СОУ . Эта
АСП должна была разрешить проблему обеспечения управляемости процесса проектирования в условиях непрерывных изменений внутренней и окружающей среды, как проектируемой системы, так и проектирующей ее системы с помощью методов математического концептуального моделирования предметной области. Должен был быть обеспечен теоретический контроль проектных процессов, начиная от формирования первичного замысла и заканчивая рабочим проектированием и созданием организации.
Сущность методологии. Перед непосредственным проектированием системы организационного управления формируется ее общая математическая концептуальная модель. Процесс проектирования сводится к управляемой конкретизации общей модели и последующей ее интерпретации. Это обеспечивает целостность проекта системы, в отличие от традиционной технологии, когда проект является совокупностью автономно разрабатываемых частей. Полученный дедуктивным способом проект затем сопоставляется с исходными требованиями. При выявлении несоответствий концептуальная модель корректируется и затем осуществляется повторное проектирование.
Таким образом, в этой методологии процесс математической концептуализации является итерационным, и он не сводится к однозначной формализации объекта и процесса проектирования, как это имеет место, например, при проектировании теплоэнергетического комплекса, осуществляемого системой МАВР.
В разработанном техническом проекте АСП СОУ методы моделирования и проектирования были ориентированы на логически направленное и поэтому управляемое теоретическое и инструментально-технологическое проектирование. Прежде всего, обеспечивалась полнота понятийного пространства проектирования за счет логического формирования всевозможных комбинаций элементов понятийной конструкции с применением морфологического и иных методов. А математическая экспликация давала возможность оперировать понятийными конструкциями вне зависимости от прикладного содержания и знакового оформления.
Функции системы АСПСОУ показаны в табл.7.1. Теоретизация предметной области основывается на выявлении проблем, установлении их системной природы и возможных путей решения. При проектировании знаковой системы определяется состав баз данных, формы документов и т.п.
Таблица 7.1 Функции Выход Вход 1. Определение и реализация концепции теоретизации предметной области
Операционная трактовка теоретических схем. Определение процедур управления с их входами и выходами
Проектирование знаковой реализации СОУ и пространственно-временной привязки.
Документирование проекта СОУ 1. Модель (теория) предметной области
Проект системы организационного управления 1. Метамодели,
описывающие поня-тия организационных систем управления и их элементов
Метамодели формализованных теорий
Для реализации этой методологии был разработан набор теоретических схем, названных конструктами, используемых для формирования с помощью логических методов теории предметной области и модели объекта проектирования. Разработка конструктов и последующий синтез конкретных теорий с контролируемым формированием производных понятий осуществлялись с использованием математического аппарата теории структур Бурбаки . Были созданы различные технологии оперирования конструктами, позволяющие на их базе формировать сложные и при этом легко изменяемые понятийные схемы.
Из описания функциональной структуры видно, что, в отличие от системы концептуального программирования ПРИЗ (см.раздел 2), теории предметной области и модели объекта проектирования являются не входом, а выходом системы АСП СОУ. А уже затем формируются проекты СОУ, как производный результат логического вывода на построенных моделях предметной области и последующей интерпретации абстрактных математических конструкций. Входом в процесс проектирования являются сформированные с использованием заранее создаваемых абстрактных метаматематических схем (конструктов), метамодели, описывающие понятия СОУ и их элементов, и метамодели, описывающие имеющиеся формализованные теории, необходимые для моделирования СОУ. К ним относятся теории технических систем, теории производственных систем, теории целенаправленных систем и т.д. Новым здесь явилось также использование аксиоматического представления теорий.
Функциональная структура АСП СОУ
Универсальность этой методологии предопределяется сформированной общей метамоделью проектируемой системы с использованием
конструктов, которые имеются в памяти системы, и возможностями ее конкретизации при проектировании. Если при интерпретации конкретизированной метамодели с помощью понятий охватываемой предметной области, СОУ и ее элементов выявляется ее неадекватность, то выбираются, либо другие способы конкретизации, либо корректируется общая концептуальная модель.
Математические модели понятий формируются с использованием различных теорий таких, таких, как теория структур, теория множеств, категорная теория систем и т.д., в разных знаковых формах - текстах, таблицах, формулах, графиках и т.д., в разных языках, шрифтах и с разным размещением на различных носителях. Это может быть выражено с помощью, предложенной в 70-х годах С.П.Никаноровым, теоретической схемы, названной «логосинотопотех». В ней выделялась логическая сущность («лог»), представляющий ее знак («син») и место расположения знака («топ») на носителе («тех»). Главным в этой схеме было семантическое отношение: «лог» раскрывает смысл знакового представления «син».
В этом подходе объектом проектирования является и функциональная структура организации и процесс ее проектирования. Методология включает дедуктивный и индуктивный этапы проектирования. Дедуктивный этап осуществляется с помощью предварительно разработанных и сохраняемых в памяти метасистемы концептуальных аксиоматических описаний необходимых областей знаний в разных математических формах - теоретико- множественной, категорной, теоретико-системной конструктов в шкалах множеств Н. Бурбаки. Потом для сформированных метамоделей системы осуществляется выбор методов и, в конечном итоге, выбор технологий с использованием базы разных теорий, моделей, методов и средств.
Индуктивный этап наступает при контроле адекватности сформированных проектов и последующем итеративном корректировании начальных теоретических схем.
Применяемость рассматриваемой методологии для проектирования организаций ограничена ориентацией на специалистов высокой квалификации, владеющих инструментарием создания и использования математических конструктов, осуществляемого в течение последних трех десятков лет научным коллективом, возглавляемым С.П. Никаноровым.
В настоящее время имеется несколько сотен конструктов и набор методов оперирования ими. Силами сравнительно небольшого коллектива специалистов был разработан информационно-программный инструментарий для автоматизированной поддержки формирования математических метамоделей предметных областей с использованием накапливаемой базы конструктов. Были созданы автоматизированная система , обеспечившая запросный режим и выполнение операций синтеза, порождения, визуализации и т.д., синтаксический и семантический анализаторы, а также лингвистический интерпретатор родов структур. Дальнейшее развитие инструментария ориентировалось на поддержку процесса проектирования организационных процедур и форм документов.
К сожалению, для реализации этой методологии при ее появлении не были разработаны детальный технологический проект и полная инструментальная система. Для получения промышленного результата требовалось задействовать мощные организации, специализирующиеся на разработке информационно-программного обеспечения, на что была нужна серьезная государственная поддержка. Когда-то академик В.М.Глушков, директор Киевского института кибернетики, говорил, что создание общегосударственной автоматизированной системы (ОГАС) необходимо финансировать так же, как космические программы или атомную промышленность. Но, к сожалению, этого не произошло.
Рассматривая эту методологию с современных позиций, видно, что в ней недостаточно внимания уделялось непосредственному, конкретному моделированию и развитию действующих организаций в рамках теорий производственных и экономических систем. Она была ориентирована на разработку новых систем, что соответствовало существовавшей в тот период времени ориентации на создание автоматизированных систем производства, проектирования и управления.
Хотя формально тогда и требовалось проведение предварительного обследования и анализа действующих систем, согласно имеющейся регламентирующей документации, и даже были разработаны детальные методики диагностического обследования и моделирования организаций, но на практике это осуществлялось редко. При отсутствии соответствующего инструментария данный этап требовал огромных усилий и времени, а результат работы проектировщиков учитывался по сданному госкомиссии проекту новой системы и ее опытному внедрению.
При выбранном методе дедуктивного формирования проекта становится затруднительным переход к имеющемуся разнообразию содержания реальных процессов, при котором осуществляется модельная интерпретация, когда элементы модели отображают конкретные элементы систем организационного управления, обозначаемые терминами исходной области знаний. В метамодельной интерпретации термам теоретических конструкций приписываются так называемые лингвистические переменные. Но как перейти к конкретным элементам системы организационного управления, если предварительно не построена ее исходная модель? И как формировать для нее математическую модель с заданным набором определенных ограничений и целевой функцией, адекватной реальности?
Такие модели нужно было создавать при развитии действующих организаций и накапливать модели-прототипы для использования при проектировании новых систем. Но надо помнить, что использование этих моделей в наглядном виде стало возможным только после появления компьютеров с большим быстродействием и огромной памятью, а также инструментальных средств, обеспечивающих формирование таких моделей. Без таких моделей невозможно производить операционное сопоставление теоретических результатов с требованиями, заданными в исходной области знаний и определять адекватность использованных абстрактных схем.
С другой стороны, если имеется конкретная содержательная модель, построенная в понятиях исходной области знаний, а инструментальная система может логически обрабатывать и нематематические понятия, то необходимо обосновать целесообразность применения математических концептуальных моделей в условиях использовании сетей компьютеров с большой памятью и быстродействием.
При использовании рассматриваемой методологии следует учитывать, что, уменьшая разнообразие и удерживая разработку системы в определенных теоретических границах, применение конструктов одновременно огрубляет предметную область, ограничивая возможности понятийного моделирования профессионалов. Когда конструкт создается, то рассматривается и идеализируется некоторая сторона сущности. Будучи созданным, конструкт может иметь много материальных и знаковых воплощений, но при этом он отображает лишь математический аналог некоторой стороны сущности, а не саму содержательную сторону сущности, которую адекватно может воспринимать профессионал в этой области. При этом природа знаний в предметных областях зачастую такова, что фразы, с помощью которых общаются профессионалы, являются лишь намеком на образы реальной сущности, возникающие у них при обучении и в результате приобретения опыта. Эти образы активизируются при восприятии фразы в сознании специалиста, но для передачи смысла фраз специалистам из других областей знаний соответствующие образы требуют расшифровки намеков.
Проблемой является и обеспечение теоретического контроля процесса создания конструктов, в частности, обоснования выбора аспектов сущности, лежащих в основе разработки математических конструкций, и корректности ее выполнения. Используемые математические конструкты должны обеспечивать интеграцию методов и средств, имеющихся в разных предметных областях, выполняя функцию их теоретической надстройки. Учитывая огромную масштабность и сложность областей знаний, которые необходимо охватывать современному разработчику, эти конструкты могут выполнять и гносеологическую функцию.
В при анализе этого подхода отмечено, что он ориентирован на прямое обеспечение при проектировании систем желаемых их свойств. Но для его реализации необходимо накопить требуемые конструкты, обеспечивающие такие возможности, опробовать необходимые методы синтеза, конкретизации и интерпретации и их программное обеспечение, доведя его до промышленного уровня. Ограниченность применения этого подхода может быть связана с проблемами перехода от общих конструктов к имеющемуся понятийному разнообразию исходной области знаний, а также с тем, что его эффективно могут реализовать только специалисты, умеющие работать с конструктами.
Полная библиография публикаций по концептуальному анализу и проектированию за период с 1967 по 2003 год приведена в . В ней представлено 742 публикации, сгруппированные по алфавиту авторов, по годам публикации и по тематике. Авторский указатель охватывает 189 авторов, а тематический - 83 рубрики.

Одна из архитектур БД называется ANSI/SPARC.

Основной идеей является выделение трехуровневой абстракции в описании данных. Цель – отделение пользовательского представления БД от ее физического представления.

Причины, по которым желательно такое разделение:

Каждый пользователь должен иметь возможность обращаться к общим данным, используя собственное представление о них;

Пользователи не должны иметь дело с подробностями физического хранения данных;

Администратор БД должен иметь возможность изменять структуру БД, не оказывая влияние на представления пользователей;

Внутренняя структура БД не должна зависеть от изменений физических аспектов хранения информации, таких как переключение на новое устройство и т.д.;

Выделяются три уровня архитектуры БД – внешний, концептуальный и внутренний.

Внешний уровень – представление БД с точки зрения пользователей, состоит из нескольких внешних представлений, обычно соответствующих группам пользователей. Различные представления могут по-разному отображать одни и те же данные, также они могут включать вычисляемые данные, не хранящиеся в БД.

Концептуальный уровень – обобщенное представление схемы БД. Уровень описывает, какие данные хранятся в БД и какие связи хранятся между ними. Концептуальная схема – это полное представление требований к данным со стороны организации, оно не зависит от способа хранения данных. На концептуальном уровне представлены следующие компоненты:

1. Все элементы данных.

2. Ограничения, накладываемые на элементы данных.

3. Семантическая информация о данных.

4. Информация о мерах обеспечения безопасностей и поддержки целостности данных.

Внутренний уровень – описывает реализацию БД и предназначен для обеспечения оптимальной производительности системы и экономного использования ее ресурсов с учетом конкретной СУБД.

Внутреннему уровню соответствует следующая информация:

1. Описание подробностей хранения с указанием реальных размеров сохраняемых элементов.

2. Распределение дискового пространства для хранения данных и индексов.

3. Сведения о физической организации данных.

4. Сведения о сжатии данных и методах их шифрования.

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

Два подхода к концептуальному проектированию: восходящий и нисходящий.

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

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

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

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

Понятие сущности.

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

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

Характеристики сущности. Проблема уникальности сущности.

В общем случае, сущность – тип или класс различимых объектов. Основанием отнесения сущности к определенному классу является наличие у сущности характеристик (атрибутов), присущих классу. Отличие сущности от остальных сущностей класса производится на основании значений этих же характеристик.

Значения большинства характеристик сущности меняются с течением времени, но это не означает исчезновение сущности и появление новой → возникает необходимость выявления характеристик сущности, которые не меняются во времени и однозначно идентифицируют сущность.

Проблема состоит в том, что на практике неизменные атрибуты найти невозможно. Даже в случае, если такие атрибуты находятся (№ зачетки и № паспорта), то в процессе эксплуатации системы может возникнуть необходимость модификации этих атрибутов, например, для исправления сделанных ошибок.

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

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

В формате IDEFX сущность определяют следующим образом:

Все наборы атрибутов, которые могли рассматриваться как ключи, помечаются АК (альтернативный ключ).

Связи. Понятие связи.

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

Пусть в предметной области существует факт – «студент обучается в группе». Это означает наличие взаимосвязи между сущностями студент и группа. При более детальном анализе выявляются дополнительные факты: студент одновременно может учиться только в одной группе, группа может состоять из многих студентов.

Такие взаимодействия отражаются как связи «один ко многим» и в стандарте IDEFX отражаются следующим образом:

В результате построения связи у сущности «студент» появился новый атрибут, помеченный FK (foreign key). Значение этого атрибута должно совпадать со значением первичного ключа сущности «группа».

В стандарте IDEFX связи «один ко многим» классифицируют по следующим признакам:

1) по возможности null-значения;

2) по степени зависимости связываемых сущностей;

3) по кардинальности;

1. Классификация связи по возможности null-значения . Продолжим пример со студентом. В какой-то момент времени студент может не принадлежать группе, например, когда студент находится в академическом отпуске или при переводе со специальности на специальность. Таким образом, атрибут «номер группы» в сущности «студент», кроме значения первичного ключа сущности «группа», может принимать null-значение.

Такая связь (с возможностью null-значения внешнего ключа) отмечается ромбом у сущности-предка.

Рассмотрим другой пример – «сотрудник работает в отделе». Проводим рассуждения, аналогичные предыдущему примеру. Если «каждый сотрудник должен работать в отделе», то между сущностями «сотрудник» и «отдел» имеется связь «один ко многим» без возможности неопределенного значения внешнего ключа. Она отображается также, только ромб у сущности-предка отсутствует.

2. Классификация связи по степени зависимости связываемых сущностей . Иногда при идентификации предмета реального мира используются характеристики, присущие другим предметам, например, специализация идентифицируется кодом специальности, которой она принадлежит и собственным номером.

071901 – первые 4 цифры – номер специальности, остальные – номер специализации. При этом номер специализации уникален в рамках специальности.

Сущности, подобные сущности «специализация», называются слабыми или зависимыми, и отображаются прямоугольниками со скругленными углами:

Связь называются идентифицирующей связью «один ко многим» и отображается не пунктирной линией и переносом первичного ключа сущности-предка в состав первичного ключа сущности-потомка. Разумеется, идентифицирующая связь не может допускать неопределенного значения внешнего ключа.

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

3. Классификация связи по кардинальности . Стандарт IDEFX поддерживает следующие кардинальности связи (рис 4):

Например, в группе должен быть хотя бы 1 студент.

Обычно при реализации базы данных сущности, между которыми есть связи «1 к 1», решаются в виде общей таблицы. Однако с семантической точки зрения объединять такие таблицы нельзя, так как получается сущность с непонятным значением.

Роль внешнего ключа.

Иногда для более точного описания предметной области вводится понятие роли атрибута для внешнего ключа. Роль – значение, которое атрибут несет, в сущности. Например, в примере о кураторе группы атрибут «табельный номер преподавателя» в сущности «группа» может играть роль «куратор». Если связь построена в обратном направлении, то внешний ключ играет роль «курируемая группа».

Бывают ситуации, когда введение роли внешнего ключа обязательно.

1) Например, когда между двумя сущностями присутствуют две или более связи → опишем бухгалтерскую проводку, которая характеризуется номером в пределах одной даты и суммой. Счет характеризуется номером, названием и разделом баланса. Между сущностями можно выделить две связи:

– «проводка кредитует счет» - один и тот же счет может кредитоваться различными проводками, а проводка кредитует только один счет → связь «один ко многим»; проводка не может не иметь счета кредитования, то есть связь не допускает неопределенного значения внешнего ключа; счет кредитования не участвует в идентификации проводки, поэтому связь не идентифицирующая;

- «проводка дебетует счет» - первичный ключ к сущности «счет» должен дважды войти в состав не ключевых атрибутов сущности «проводка», то есть обойтись без роли внешнего ключа нельзя:

2) в случае рекурсивной связи - когда родитель и потомок совпадают. Пример – иерархия подчинения в организации, когда для данного работника необходимо учитывать его непосредственного начальника:

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Введение

1. Концептуальное проектирование

1.1 Определение типов сущности

1.2 Определение атрибутов и связывание их с типами сущности

1.3 Определение доменов атрибутов

1.4 Сведения об альтернативных и первичных ключах

2. Логическое проектирование

2.1 Преобразование локально концептуальной модели данных в локальную логическую модель

2.2 Проверка моделей с помощью правил нормализации

2.3 Проверка модели в отношении транзакций пользователя и выполнения запросов

2.4 Построение окончательной диаграммы "Сущность связь"

Заключение

Список использованной литературы

Введение

База данных - представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).

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

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

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

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

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

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

Часто класс объектов называют сущностью. Каждая сущность обладает атрибутами. Атрибут - это свойство объекта, характеризующее его экземпляр. Сущность "студент" может иметь атрибуты "имя", "год рождения", " дата поступления" и т. д. Таким образом сущность можно определить, как множество индивидуальных объектов одного типа (экземпляров), причем все эти объекты различны, т. е. набор атрибутов одинаков, а их значения различны.

Цель моей работы - разработать базу данных для учета продаж и доставок товаров комплектов и комплектующих ПК. Так же это будет использоваться учета движения товара между поставщиком и получателем.

Задачи работы:

Определить типы сущностей

Определить типы связи

Определить атрибуты и связать их с сущностями

Определить домены атрибутов

Определить альтернативные ключи (атрибуты)

Создать диаграмму "сущность связь"

Преобразовать локально концептуальную модель в локальную логическую модель данных

Проверить модели с помощью правил нормализации

Проверить модель в отношении транзакций пользователя и выполнить запросы

Построить окончательную диаграмму "Сущность связь"

1. Концептуальное проектирование

Концептуальное (инфологическое) проектирование - построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины "семантическая модель", "концептуальная модель" и "инфологическая модель" являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова "модель базы данных" и "модель предметной области" (например, "концептуальная модель базы данных" и "концептуальная модель предметной области"), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.

Чаще всего концептуальная модель базы данных включает в себя:

Описание информационных объектов или понятий предметной области и связей между ними.

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

1.1 Определение типов сущности

Сущность - любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности.

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

Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром - Москва, Киев и т.д.

Выделяют три вида сущностей: стержневая, ассоциативная (ассоциация) и характеристическая (характеристика). Кроме этого во множестве ассоциативных сущностей также определяют подмножество обозначений. Дадим теперь определение видам сущностей.

Стержневая сущность.

Стержневая (сильная) сущность - независящая от других сущность. Стержневая сущность не может быть ассоциацией, характеристикой или обозначением (см. ниже).

Ассоциация.

Ассоциативная сущность (или ассоциация) выражает собой связь "многие ко многим" между двумя сущностями. Является вполне самостоятельной сущностью. Например, между сущностями МУЖЧИНА и ЖЕНЩИНА существует ассоциативная связь, выражаемая ассоциативной сущностью БРАК.

Характеристика.

Характеристическую сущность еще называют слабой сущностью. Она связана с более сильной сущностью связями "один ко многим" и "один к одному". Характеристическая сущность описывает или уточняет другую сущность. Она полностью зависит от нее и исчезает с исчезновением последней.

Обозначение.

Обозначение это такая сущность, с которой другие сущности связаны по принципу "многие к одному" или "один к одному". Обозначение, в отличие характеристики является самостоятельной сущностью. Например, сущность Факультет обозначает принадлежность студента к данному подразделению института, но является вполне самостоятельной.

Определение типов связи

Связь - это графически изображаемая ассоциация, устанавливаемая между двумя типами сущностей. Как и сущность, связь - это типовое понятие, все экземпляры обоих связываемых типов сущностей подчиняются устанавливаемым правилам связывания. Поэтому правильнее говорить о типе связи, устанавливаемой между типами сущности, и об экземплярах типа связи, устанавливаемых между экземплярами типа сущности. В обсуждаемом здесь варианте ER-модели эта ассоциация всегда является бинарной и может существовать между двумя разными типами сущностей или между типом сущности и им же самим (рекурсивная связь). В любой связи выделяются два конца (в соответствии с существующей парой связываемых сущностей), на каждом из которых указываются имя конца связи, степень конца связи (сколько экземпляров данного типа сущности должно присутствовать в каждом экземпляре данного типа связи), обязательность связи (т. е. любой ли экземпляр данного типа сущности должен участвовать в некотором экземпляре данного типа связи).

Связь представляется в виде. При этом в месте "стыковки" связи с сущностью используются:

Трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут (или должны) использоваться много экземпляров сущности;

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

Обязательный конец связи изображается сплошной линией, а необязательный - прерывистой линией.

Связь между сущностями БИЛЕТ и ПАССАЖИР, связывает билеты и пассажиров. Конец связи с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец связи с именем "имеет" показывает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

Рис. 1 . Пример типа связи

· каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;

· каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

Рекурсивная связь

На следующем примере (рис. 2) изображена рекурсивная связь, связывающая сущность МУЖЧИНА с ней же самой. Конец связи с именем "сын" определяет тот факт, что несколько людей могут быть сыновьями одного отца. Конец связи с именем "отец" означает, что не у каждого мужчины должны быть сыновья.

Рис. 2 . Пример рекурсивного типа связи

Лаконичная устная трактовка изображенной диаграммы состоит в следующем:

Каждый МУЖЧИНА является сыном одного и только одного МУЖЧИНЫ;

Каждый МУЖЧИНА может являться отцом одного или более МУЖЧИН.

Виды связей между таблицами

Связь позволяет моделировать отношения между объектами предметной области.

Существует 4 типа связей:

1. " Один-к-одному " - любому экземпляру сущности А соответствует только один экземпляр сущности В, и наоборот.

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

2. " Один-ко-многим " - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, но любому экземпляру сущности В соответствует только один экземпляр сущности А.

Ученику ставят много оценок; поставленная оценка принадлежит только одному ученику.

3. " Многие-к-одному " - любому экземпляру сущности А соответствует только один экземпляр сущности В, но любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

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

4. " Многие-ко-многим " - любому экземпляру сущности А соответствует 0, 1 или несколько экземпляров сущности В, и любому экземпляру сущности В соответствует 0, 1 или несколько экземпляров сущности А.

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

1.2 Определение атрибутов и связывание их с типами сущности

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

Пример типа сущности ЧЕЛОВЕК с указанными атрибутами показан на (рис.3) С технической точки зрения атрибуты типа сущности в ER-модели похожи на атрибуты отношения в реляционной модели данных. И в том, и в другом случаях введение именованных атрибутов вводит некоторую типовую структуру данных, имя которой совпадает с именем типа сущности в случае ER-модели или с именем переменной отношения в случае реляционной модели. Этой типовой структуре должны следовать все экземпляры типа сущности или все кортежи отношения.

Рис. 3. Пример типа сущности с атрибутами

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

Как отмечалось выше, при определении типа сущности необходимо гарантировать, что каждый экземпляр сущности является отличимым от любого другого экземпляра той же сущности. Поскольку сущность является абстракцией реального или представляемого объекта внешнего мира, это требование нужно иметь в виду уже при выборе кандидата в типы сущности. Уникальным идентификатором сущности может быть атрибут, комбинация атрибутов, связь, комбинация связей или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа. Приведем несколько примеров. На (рис. 4) показан тип сущности КНИГА, пригодный для использования в базе данных книжного склада. При издании любой книги в любом издательстве ей присваивается уникальный номер - ISBN. Понятно, что значение атрибута isbn будет уникально идентифицировать партию книг на складе. Кроме того, конечно, в качестве уникального идентификатора годится и комбинация атрибутов <автор, название, номер издания, издательство, год издания>.

Рис. 4 Тип сущности, экземпляры которого идентифицируются атрибутами

На (рис. 5) диаграмма включает два связанных типа сущности. У каждого взрослого человека имеется один и только один и каждый паспорт может принадлежать только одному взрослому человеку. Тогда связь человека с его паспортом уникально идентифицирует взрослого человека, т. е., грубо говоря, паспорт определяет взрослого человека. Поскольку могут существовать паспорта, еще не выданные какому-либо человеку, эта связь не является уникальным идентификатором сущности ПАСПОРТ.

Рис. 5 Тип сущности, экземпляры которого идентифицируются связью

На (рис. 6) диаграмма включает три связанных типа сущности. Профессора обладают знаниями в нескольких учебных дисциплинах. Преподавание каждой дисциплины доступно нескольким профессорам. Другими словами, между сущностями ПРОФЕССОР и ДИСЦИПЛИНА определена связь "многие ко многим". Каждый профессор может готовить курсы по любой доступной ему дисциплине. Каждой дисциплине может быть посвящено несколько учебных курсов. Но каждый профессор может готовить только один курс по любой доступной ему дисциплине, и каждый курс может быть посвящен только одной дисциплине. Тем самым, каждый экземпляр типа сущности КУРС уникально идентифицируется экземпляром сущности ПРОФЕССОР и экземпляром сущности ДИСЦИПЛИНА, т. е. парой связей с именами концов ГОТОВИТСЯ и ПОСВЯЩЕН на стороне сущности КУРС. Заметим, что сущности ПРОФЕССОР и ДИСЦИПЛИНА связями не идентифицируются.

Рис. 6 . Тип сущности, экземпляры которого идентифицируются комбинацией связей

Наконец, на (рис. 7) приведен пример типа сущности, уникальный идентификатор которого является комбинацией атрибутов и связей. У каждого человека могут быть дети, и у каждого человека имеется отец. Тогда, если предположить, что близнецам, появившимся на свет одновременно, не дают одинаковых имен, то уникальным идентификатором типа сущности ЧЕЛОВЕК может быть комбинация атрибутов.

Рис. 7 . Тип сущности, экземпляры которого идентифицируются комбинацией атрибутов и связей

1.3 Определение доменов атрибутов

Домен в реляционной модели данных - тип данных, то есть допустимое множество значений.

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

Примерами могут являться типы "целое" (множество всех целых чисел), "строка" (множество всех строк), "номер детали" (множество всех номеров деталей) и т. д. Таким образом, когда мы говорим, что некоторое отношение имеет атрибут типа "целое", мы имеем в виду, что все значения этого атрибута принадлежат множеству "целое" и никакому другому.

По аналогии с математикой, типы данных делят на скалярные и нескалярные . Значение нескалярного типа (нескалярное значение) имеет множество видимых пользователю компонентов, а значение скалярного типа (скалярное значение) не имеет такового. Примерами нескалярного типа являются тип отношения и тип кортежа; пример скалярного типа - тип "целое".

Ограничения реализации систем баз данных на компьютерах накладывают на определение типов некоторую условность. Так, теоретически тип INTEGER представляет собой множество всех возможных целых чисел, однако фактически INTEGER - это множество всех целых чисел, которые могут быть представлены в рассматриваемой компьютерной системе (поскольку, безусловно, есть такие целые числа, которые превышают возможности представления в любой компьютерной системе).

Следует отличать тип как таковой (логическое понятие) и формат физического представление значений этого типа в конкретной компьютерной системе; типы относятся к уровню логической модели , а физическое представление значений - к уровню реализации . Например, операции, определённые для типа "строка", не имеют смысла для типа "число", даже если числа в конкретной реализации физически представлены строками. Значения типа "дата" нередко физически представлены вещественным числом, однако большинство операций, имеющих смысл для типа "число", бессмысленны для типа "дата".

Реляционная модель данных не предписывает обязательной поддержки каких-либо предопределённых типов, за исключением логического типа (BOOLEAN), без которого при выполнении операций обойтись невозможно. Обычно некоторый набор типов поддерживается системой, другие типы пользователь может конструировать дополнительно.

1.4 Сведения об альтернативных и первичных ключах

Перви чный ключ - в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию).

Если в отношении имеется единственный потенциальный ключ, он является и первичным ключом. Если потенциальных ключей несколько, один из них выбирается в качестве первичного, а другие называют "альтернативными ".

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

1.6 Построение диаграммы сущность-связь

2. Логическое проектирование

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

2.1 Преобразование локально концептуальной модели данных в локальную логическую модель

1. Первым этапом является удаление связи "многие ко многим". Такая связь присутствует между сущностями "Комплект" и "Фирма заказчик". Разобьем эти связи путем введения промежуточной сущности "Список"

2. Удаление сложных связей. Сложные связи это связи в которых учавствуют три и более типов сущностей. В моей работе таких связей нет.

3. Удаление рекурсивных связей. Рекурсивные связи - связи в которые сущности взаимодействуют сами с сбой. В моей работе таких связей нет.

4. Удаление связей с атрибутами.

5. Удаление множественных атрибутов в моей работе есть один множественный атрибут -телефон. Разделим "телефон получателя" на "домашний телефон получателя" и "мобильные телефон получателя". "Телефон поставщика" на "мобильный телефон поставщика" и "домашний телефон поставщика".

6. Удаление избыточных связей. В моей работе таких связей нет.

2.2 Проверка моделей с помощью правил нормализации

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

В теории реляционных баз данных обычно выделяетсяследущая последовательность нормальных форм:

1. 1 нормальная форма

2. 2 нормальная форма

3. 3 нормальная форма

Первая нормальная форма (1NF)

Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.

В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1НФ.

Вторая нормальная форма (2NF)

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

Третья нормальная форма (3NF)

Переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме, и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых.

2.3 Проверка модели в отношении транзакций пользователя и выполнения запросов

1. Сведения об имеющихся комплектующих указанного источника;

SELECT комплектующие. название комплектующей, фирма поставщик. название фирмы поставщика, комплектующие, номер поставщика

FROM комплектующие, поставщик

WHERE фирма поставщик, название фирмы поставщика "AMD"

AND фирма поставщик, номер фирмы поставщика=комплектующие, номер фирмы поставщика;

2. Сведения об комплектах, заказанных определенным заказчиком с указателем имени получателя;

SELECT комплект, название комплекта, список, номер комплекта, номер фирмы заказчика, фирма заказчик, название фирмы заказчика, получатель, ФИО получателя

FROM комплект, список, заказчик, получатель

WHERE фирма заказчик, название фирмы заказчика- "Интерком"

AND список номер комплекта-комплект. номер комплекта AND список, номер фирмы заказчика=фирма заказчик, номер фирмы заказчика AND получатель, номер получателя=комплект номер получателя;

2.4 Построение окончательной диаграммы " Сущность связь "

Заключение

В данной курсовой работе я разработал базу данных для автоматизации работы компьютерного салона. На начальном этапе я составил модель предметной области, которой необходимо определить объекты, которые представляют наибольший интерес для пользователей. Для этого я составил подробное описание предметной области и связей, которые присутствуют между данными объектами, проверил свою модель на наличие таких видов связей как сложная, рекурсивная, связь с атрибутами, разделил связи многие ко многим, а также определил типы сущности и типы атрибутов, и на основании этих данных построил диаграмму "сущность-связь"

На 2 уровне я сделал проверку связи и проверку моделей с помощью правил нормализации. Моя модель данных находилась в первой и второй нормальной форме, в 3 нормальную форму я привел модель путем нахождения транзитивных зависимостей и перенесением их в другую сущность (список). Проверил модель в отношении транзакций пользователей и выполнения запросов, а затем построил окончательную диаграмму "сущность-связь". На основе проведенной мной работы могу сказать, что моя база данных будет хорошо помогать в работе компьютерного салона.

Список использованной литературы

1. Базы данных. Учебник А.Д. Хомоненко

2. Вейскос Дж. Эффективная работа с MS Access 2000

3. Википедия

4. Дейт К. Дж. Введение в систему баз данных

Размещено на Allbest.ru

...

Подобные документы

Исходные данные для проектирования комплекса производств лакокрасочных материалов и растворителей общей мощностью 7000 т/г. Основание для разработки исходных данных и общие сведения о технологии. Описание принципиальных технологических схем производства.

курсовая работа , добавлен 17.02.2009


Характеристика этапов автоматизированного проектирования. Методика и алгоритм расчета норм расхода основных материалов на женское демисезонное пальто с помощью программ Basiq Norma 1 и Norma 2. Особенности автоматизации обработки данных с помощью ЭВМ.

курсовая работа , добавлен 06.05.2010


Подбор электродвигателя и проектирование двухступенчатого червячного редуктора. Критерии проектирования: выбор размеров и материалов редуктора. Расчет быстроходной и тихоходной передачи. Конструирование червяков и червячных колес. Компоновка редуктора.

курсовая работа , добавлен 12.01.2012


Составление исходных данных для проектирования птичника. Определение требуемого термического сопротивления теплопередаче. Расчет площадей отдельных зон пола. Расчет теплопотери через ограждающие конструкции. Расчет тепловоздушного режима и воздухообмена.

курсовая работа , добавлен 10.09.2010


Основные сведения о силикатном кирпиче. Производство известково-кремнеземистого вяжущего. Силос для гашения сырьевой смеси. Процесс автоклавной обработки материалов. Расчет потребности сырья. Входной контроль материалов. Расчет проектирования складов.

дипломная работа , добавлен 27.01.2014


Правила проектирования и реконструкции механических производственных цехов: общие сведения о проектировании механосборочного производства, описание рабочего проекта и рабочей документации, интерьера спроектированного участка изготовления детали.

контрольная работа , добавлен 28.12.2008


Характеристика продукции завода железобетонных изделий и бетонных смесей. Расчет производительности программы приготовления бетонных смесей. Выбор технологического оборудования. Определение объемов запасов хранения материалов и выбор типов складов.

курсовая работа , добавлен 11.06.2015


Функции системы автоматизированного проектирования одежды. Художественное проектирование моделей одежды. Антропометрический анализ фигур. Методы проектирования конструкций моделей. Разработка семейства моделей, разработка лекал и определение норм расхода.

дипломная работа , добавлен 26.06.2009


Условия эксплуатации машинного агрегата, служащего приводом качающегося подъемника. Двигатель для его проектирования, кинематический расчет привода. Выбор материалов червячной передачи и определение допускаемых напряжений. Расчет валов и подшипников.

курсовая работа , добавлен 16.06.2011


Обоснование выбора системы и схемы водопровода, гидравлический расчет сети и подбор счетчика. Определение требуемого напора. Нормы проектирования канализационной системы, расчет внутренней и дворовой сети. Спецификация материалов и оборудования.