Порядок проведения АВС-анализа1. Определяем цель анализа (а зачем собственно нужен вам этот анализ?). 2. Определяем действия по итогам анализа (что будем делать с полученными результатами?). 3. Выбираем объект анализа (что будем анализировать?) и параметр анализа (по какому признаку будем анализировать?). Обычно объектами АВС анализа являются поставщики, товарные группы, товарные категории, товарные позиции. Каждый из этих объектов имеет разные параметры описания и измерения: объём продаж (в денежном или количественном измерении), доход (в денежном измерении), товарный запас, оборачиваемость и т. д. 4. Составляем рейтинговый список объектов по убыванию значения параметра. 5. Рассчитываем долю параметра от общей суммы параметров с накопительным итогом. Доля с накопительным итогом высчитывается путём прибавления параметра к сумме предыдущих параметров. 6. Выделяем группы А, В и С: присваиваем значения групп выбранным объектам. Методов выделения групп существует порядка десяти, наиболее применимы из них: эмпирический метод, метод суммы и метод касательных. В эмпирическом методе разделение происходит в классической пропорции 80/15/5. В методе суммы складывается доля объектов и их совокупная доля в результате — таким образом значение суммы находится в диапазоне от 0 до 200 %. Группы выделяют так: группа А — 100 %, В — 45 %, С — остальное. Достоинства метода — большая гибкость. Самым гибким методом является метод касательных, в котором к кривой АВС проводится касательная, отделяя сначала группу А, а затем С. Вероятности возникновения спроса на материальные ресурсы А, В и С подчинены различным законам. Установлено, что в большинстве промышленных и торговых фирм примерно 75 % стоимости объёма продаж составляют всего около 10 % наименований номенклатуры (группа А), 20 % стоимости — 25 % наименований (группа В), 5 % стоимости — 65 % наименований (группа С). Существует множество способов выделения групп в ABC-анализе. Метод АВС широко используется при планировании и формировании ассортимента на различных уровнях гибких логистических систем, в производственных системах, системах снабжения и сбыта. Эксперты советуют с осторожностью подходить к сдвигам границ ABC групп (80/15/5), дело в том, что обычно на практике используют деление 80 % 15 % и 5 %. В случае если Вы сдвинете границы, внешний слушатель(или эксперт) может сделать неверные выводы исходя из приведенных Вами показателей например для группы «С». Так как его ожидания о группе «С» = 5 % не совпадут с измененными Вами правилами выделения групп. XYZ- анализ позволяет произвести классификацию ресурсов компании в зависимости от характера их потребления и точности прогнозирования изменений в их потребности в течение определенного временного цикла. Алгоритм проведения можно представить в четырёх этапах: 1. Определение коэффициентов вариации для анализируемых ресурсов; 2. Группировка ресурсов в соответствии с возрастанием коэффициента вариации; 3. Распределение по категориям X, Y, Z. 4. Графическое представление результатов анализа. Категория X — ресурсы характеризуются стабильной величиной потребления, незначительными колебаниями в их расходе и высокой точностью прогноза. Значение коэффициента вариации находится в интервале от 0 до 10 %. Категория Y — ресурсы характеризуются известными тенденциями определения потребности в них (например, сезонными колебаниями) и средними возможностями их прогнозирования. Значение коэффициента вариации — от 10 до 25 %. Категория Z — потребление ресурсов нерегулярно, какие-либо тенденции отсутствуют, точность прогнозирования невысокая. Значение коэффициента вариации — свыше 25 %. Реальное значение коэффициента вариации для разных групп может отличаться по следующим причинам: § сезонность продаж, § тренд, § акции, § дефицит и т. д. Есть несколько разновидностей XYZ-анализа, например анализ плановых данных с фактическими, что дает более точный % отклонения от прогноза. Очень часто XYZ-анализ проводят совместно с ABC-анализом позволяя выделять более точные группы, относительно их свойств.
Здесь полный материал по Архитектуре БД, основным этапам проектирования БД и модели данных. Системы управления базами данных Введение Эффективность функционирования информационной системы предприятия во многом определяется уровнем разработки информационного обеспечения. Большое значение при этом имеет технология создания и эксплуатации баз данных. База данных (БД) является интегрированной системой обработки информации, способствующей сокращению избыточности в хранении данных, совместному использованию информации различными пользователями, удобству доступа к данным и безопасности их хранения. База данных является основным средством создания и хранения информационной модели предприятия. В связи с этим актуальным является освоение принципов создания и эксплуатации баз данных. Изучение технологии баз данных дает необходимые знания для создания и проектирования организованных массивов информации и показывает ее роль в системе управления предприятием. Теория баз данных - сравнительно молодая область знаний. Однако теория баз данных является обязательной для изучения студентами широкого круга специальностей: от специалистов по вычислительной технике и других технических специальностей до экономистов и менеджеров, у которых данный раздел включен в такие дисциплины, как информатика, информационные технологии управления, информационные технологии в социальной сфере. 1. История развития систем управления базами данных Развитие вычислительной техники в основном шло в двух направлениях: для выполнения численных расчетов и для использования в автоматизированных информационных системах. Развитие первого направления привело к появлению языков программирования и способствовало интенсификации методов численного решения математических задач. Использование вычислительной техники в автоматизированных информационных системах началось несколько позже, что связано с ограниченностью возможностей хранения информации. История развития систем управления базами данных (СУБД) начинается с 1968 года, когда была введена в эксплуатацию первая промышленная система управления данными IMS фирмы IBM. В развитии СУБД можно выделить четыре этапа. Между ними нет четкой границы: они плавно переходят один в другой и сосуществуют параллельно. Первый этап связан с организацией БД на больших машинах типа ЕС-ЭВМ. Базы данных хранились во внешней памяти центральной ЭВМ, режим доступа обеспечивался с помощью терминалов, которые служили только как устройства ввода-вывода для центральной ЭВМ. Эти системы можно отнести к системам распределенного доступа, потому что база данных была централизованной, а доступ к ней поддерживался от многих пользователей-задач. Второй этап связан с появлением персонального компьютера. Разрабатывались различные программы для работы с базами данных, которые имели удобный интерфейс и средства для расчетов. Яркие представители этого семейства, очень широко использовавшиеся до недавнего времени, это СУБД Dbase (DbaseIII+ Dbase IV), FoxPro, Clipper, Paradox. Все СУБД этого этапа были рассчитаны на создание базы данных с монопольным доступом. Наличие монопольного режима работы фактически привело к вырождению функций администрирования и в связи с этим – к отсутствию инструментальных средств администрирования баз данных. Однако доступность ПК привела к активной компьютеризации тех областей, которые ранее не применяли ВТ в своей деятельности. Кроме того, настольные (desktop) СУБД предъявляли достаточно скромные требования к аппаратному обеспечению (PC 286). Третий этап развития баз данных начался в 80-е годы и продолжается до настоящего времени и связан с появлением и широким внедрением локальных сетей. Остро встает задача согласованности данных, хранящихся и обрабатывающихся в различных местах, но логически друг с другом связанных. Успешное решение этой задачи приводит к появлению распределенных баз данных, позволяющих организовать параллельную обработку информации и поддержку целостности баз данных. Четвертый этап, который в данный момент активно развивается, характеризуется появлением новой технологии доступа к данным – интранет. Интранет технология представляет собой внутреннюю корпоративную компьютерную сеть, собственный web-портал предприятия. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для доступа к данным используются HTML-страницы. 2. Основные понятия и определения Важнейшим понятием в теории баз данных является информация. Под информацией понимаются любые сведения о каком-либо событии, процессе, объекте. К информации может относиться все, что может интересовать пользователя любого уровня. Для того, чтобы автоматизировать процесс сбора, хранения и обработки информации, она должна быть представлена в определенном виде. Информация в виде, пригодном для дальнейшей автоматизированной обработки называется данными. Например, отчет о продажах – это информация. А конкретные показатели продаж (цена, количество проданных единиц товара, фамилии продавцов), которые непосредственно будут вводится в БД, - это данные. После обработки данные вновь преобразуются в информацию, то есть в форму, которая является значимой и полезной. Например, графики продаж, прогнозы, анализ чувствительности и др. Банк данных - это система специальным образом организованных данных - баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных. База данных - именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области. Система управления базами данных - совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями. БД содержит не только данные, но и описания этих данных. Информация о данных, хранимых в БД, называется метаданными. Программы, с помощью которых пользователи работают с базой данных, называются приложениями. С одной БД могут работать несколько приложений. Например, если БД моделирует некоторое предприятие, то для работы с ней может быть создано приложение, которое обслуживает подсистему учета кадров, следующее приложение может обеспечивать работу подсистемы заработной платы сотрудников, другие – подсистемы складского учета, планирования производственного процесса и т.д. Приложения могут работать параллельно и независимо друг от друга, а СУБД призвана обеспечить их работу таким образом, чтобы каждое из них выполнялось корректно, и учитывало все изменения в БД, вносимые другими приложениями. Пользователи БД. С созданием и функционированием базы данных связаны различные категории пользователей. Конечные пользователи. Основная категория. В нее могут входить случайные пользователи или сотрудники, от которых не требуется специальных знаний в области ВТ. Администраторы банка данных. Отвечают за оптимальную организацию и корректность работы базы данных в многопользовательском режиме. Разработчики и администраторы приложений. Задействованы при проектировании, создании и реорганизации базы данных. Администраторы координируют работу разработчиков конкретных приложений. 3. Архитектура базы данных В настоящий момент используется предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая модель БД
В ней отражены два независимых взгляда на БД - взгляд пользователя, часто называемый логическим представлением данных, и "взгляд" системы, называемый физическим представлением данных, который характеризует организацию хранимых данных. Пользователя не интересуют при его работе с БД байты и биты, представляющие данные в среде хранения, но все эти факторы важны для выполнения функций управления данными самой СУБД. Таким образом, одна и та же БД в зависимости от точки зрения может иметь различные уровни описания: внешний, концептуальный и внутренний. Конечные пользователи имеют дело с представлениями базы данных на внешнем уровне. Описания таких представлений называются внешними схемами или подсхемами. В системе базы данных может одновременно поддерживаться несколько внешних схем для различных групп пользователей и/или приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Концептуальный уровень является центральным управляющим звеном БД. На этом уровне БД представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, и отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась БД. Представление базы данных на концептуальном уровне системы описывается концептуальной схемой базы данных. Механизмы СУБД, поддерживающие внутренний уровень архитектуры, служат для поддержки представления базы данных в среде хранения. На этом уровне БД представлена в "материализованном" виде: байты и биты, их размещение в памяти, указатели, поддерживающие связи между различными структурными компонентами хранимых данных, выбранные методы доступа и пр. Описание представления базы данных на внутреннем уровне архитектуры называется внутренней схемой или схемой хранения. Ключевой концепцией трехуровневой архитектуры БД является концепция независимости данных. Различают логическую (между внешним и концептуальным уровнями) и физическую (между концептуальным и внутренним уровнями) независимость данных. Обеспечение логической независимости данных означает возможность изменения логической структуры данных на концептуальном уровне без необходимости соответствующей модификации приложений и пользовательских запросов. Под физической независимостью данных понимается возможность вносить изменения в организацию хранимых данных, не затрагивая логическую структуру БД и созданных прикладных программ, использующих базу данных. Следует еще раз подчеркнуть, что в отличие от хранимой базы данных, концептуальные и внешние схемы являются виртуальными. Составляющие их данные материализуются только при обращении к ним. В предлагаемой архитектурной модели необходимо поддерживать соответствие между представлениями БД на смежных уровнях архитектуры. В модели ANSI для этой цели служат механизмы междууровневого отображения данных "внешний - концептуальный" и "концептуальный - внутренний". Именно эти механизмы обеспечивают абстракцию данных в системе, определяют достижимую в системе степень независимости данных. Модели данных Сами по себе данные не обладают определенной структурой, данные становятся информацией тогда, когда пользователь задает им определенную структуру, то есть, осознает их смысловое содержание. Поэтому центральным понятием в области БД является понятие модели. Модель данных - это некоторая абстракция, которая используется, чтобы трактовать данные как информацию (то есть сведения, содержащие не только данные, но и взаимосвязь между ними). Например, «Петров», «Иванов», «Сидоров», «600», «700», «900» – это данные, а: «Петров зарабатывает 600 р. в день», «Иванов – 700 р.», «Сидоров – 900 р.» – это информация. Классификация моделей данных приведена на рисунке 13. Все модели данных можно разделить на инфологические, даталогические и физические. Физические модели данных Физические модели баз данных описывают то, как данные хранятся в компьютере, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа. Физическая организация БД является коммерческой тайной для большинства специализированных СУБД. Каждый разработчик старается создать свою уникальную структуру данных. Среди них можно выделить способы размещения данных, основанные на файловых структурах и на страничной организации данных.
Файловые структуры и системы управления файлами являются частью операционной системы. СУБД создает свою надстройку, которая работает с файлами. В технологии БД могут использоваться файлы прямого, последовательного доступа, индексные, инвертированные списки и взаимосвязанные файлы. Но такая технология является неэффективной по отношению к базам данных, где необходимо обрабатывать большие объемы информации. Поэтому современные СУБД работают по несколько иным принципам управления внешней памятью. В технологии страниц данных СУБД сама размещает данные на внешних носителях, а операционная среда не получает непосредственного доступа к этому пространству. При страничной организации данных все данные хранятся во внешней памяти постранично. БД выглядит как набор записей, которые просматриваются с помощью встроенного диспетчера файлов. С точки зрения диспетчера файлов БД выглядит как набор страниц, которые могут просматриваться с помощью диспетчера дисков. Даталогические модели Если физические модели данных соответствуют внутреннему уровню трехуровневой архитектуры БД, то даталогические и инфологические модели – концептуальному; то есть, они предназначены для моделирования предметной области. Здесь отражаются все объекты, их свойства и связи между ними. Внешние модели (подсхемы) используют те же абстрактные категории, что и концептуальные модели данных. Даталогические модели можно разделить на документальные и фактографические. Документальные модели предназначены для работы со слабоструктурированной информацией. Они ориентированы в основном на свободные форматы документов, тексты на естественном языке. В свою очередь, среди документальных моделей выделяют гипертекстовые, классификационные, дескрипторные (описываются определенные характеристики документа) и пр. Документальные модели подробно рассмотрены в следующей теме. Среди фактографических моделей выделяют теоретико-графовые, теоретико-множественные и объектно-ориентированные. Теоретико-графовые модели отражают совокупность объектов реального мира в виде графа взаимосвязанных информационных объектов. В зависимости от типа графа выделяют иерархическую и сетевую модели. Теоретико-множественные модели используют математический аппарат, реляционную алгебру, реляционное исчисление. Основным представителем данной группы является реляционная модель данных. Объектно-ориентированные модели базируются на концепции объектно-ориентированного программирования. Предметная область представляется в виде объектов, каждому из которых присущи свои свойства, методы и события. Инфологические модели Инфологические (информационно-логические) модели, как и даталогические, используются для моделирования предметной области на концептуальном уровне. Они достаточно близки по смыслу и отличаются тем, что все даталогические модели разрабатывались для функционирования конкретных СУБД. Например, сетевая модель данных впервые использовалась в СУБД IDS компании General Electric, а самая известная иерархическая модель - в СУБД IMS компании IBM. Инфологические модели выражают информацию в виде, не зависящем от используемой СУБД. Они отражают в естественной форме информационно-логический уровень абстрагирования, связанный с описанием объектов, их свойств и взаимосвязей. Также они называются семантическими моделями, то есть эти модели способны отражать смысловое содержание объектов реального мира. Инфологические модели используются на ранних стадиях проектирования для описания структур данных и их взаимосвязей. Как правило, после выбора СУБД, в которой будут реализована база данных, такие модели легко преобразуются в соответствующие даталогические модели. В семидесятых годах было предложено несколько моделей данных, названных семантическими. В настоящий момент наиболее широкое распространение получила модель Чена (Chen), предложенная в 1976 году, которая получила название «сущность-связь» или ER-модель (“Entity Relationship”). Большинство современных CASE средств (системы автоматизированного проектирования информационных систем) содержат инструменты для описания данных в терминах ER-модели. Далее представлены основные концепции некоторых наиболее известных моделей, в том числе ER-модели и реляционной модели данных. Иерархическая модель данных Иерархическая модель данных является наиболее простой среди даталогических моделей. Основными единицами в иерархической модели являются база данных, сегмент (запись) и поле. Например, для базы данных университета факультет, студент, группа – это сегменты. Фамилия, имя, номер зачетной книжки – поля сегмента «студент». Иванов Сергей 907312 – это экземпляр сегмента. Экземпляр сегмента образуется из конкретных значений входящих в него данных.
В иерархической модели сегменты объединяются в древовидный граф (рис. 14). Сегмент, находящийся на более высоком уровне иерархии, называется логически исходным по отношению к сегментам, соединенным с ним, которые, в свою очередь, называются логически подчиненными. Например, А – логически исходный сегмент по отношению к В и С, С - логически исходный сегмент по отношению к D и Е. Схема иерархической БД представляет собой совокупность отдельных деревьев, каждое из которых называется физической БД и удовлетворяет следующим ограничениям: · в каждой физической БД существует один корневой сегмент (то есть сегмент, у которого нет логически исходного); · каждый логически исходный сегмент может быть связан с произвольным числом подчиненных сегментов; · каждый логически подчиненный сегмент может быть связан только с одним логически исходным сегментом. Пример иерархической модели такой структуры, как факультет представлен на рис. 15.
Здесь показаны не только связи, но и их смысловое содержание. На факультете может быть несколько кафедр. На каждой кафедре могут работать преподаватели. На факультете обучается несколько групп. В группах учатся студенты. Сетевая модель данных Сетевая модель также, как и иерархическая, является графовой моделью данных, так как отображается в виде графа. В сетевой модели используется следующая терминология: элемент данных (аналог поля), запись (аналог сегмента), набор и база данных. В отличие от иерархической, в сетевой модели подчиненный сегмент может иметь произвольное число исходных сегментов. Кроме того, между двумя сегментами (записями) может быть несколько связей. Каждая такая бинарная связь называется набором. На рис. 16 приведен пример сетевой модели БД «Факультет».
Здесь записи «Преподаватели» и «Группы» связаны двумя связями: преподаватель может быть куратором группы и преподаватель преподает в нескольких группах. Записи «Группы» и «Студенты» связаны связью «Учатся». Каждой из связей можно сопоставить свой набор. На рис. 17 в качестве примера представлены диаграммы наборов «Куратор», «Преподает» и «Учатся».
Модель «сущность-связь» (ER-модель) Модель «сущность-связь», также называемая как ER-модель, была предложена П.Ченом в 1976 году и с тех пор неоднократно усовершенствовалась. В основе этой модели лежат следующие базовые понятия. Сущность – это класс однотипных объектов. Сущность имеет уникальное имя. Предполагается, что в системе существует множество экземпляров данной сущности. Например, «студент», «преподаватель» - это сущности. Экземплярами сущности «студент» будут конкретные студенты вуза (Иванов, Петров, Степанов и пр.), сущности «преподаватель» - преподаватели вуза (Захаров И.С., Бронштейн И.А. и пр.). Объект имеет свой набор атрибутов – свойств объекта. Для сущности «студент» можно выделить такие атрибуты как «номер зачетной книжки», «фамилия», «имя», «отчество», «номер групп». Для сущности «преподаватель» – «табельный номер», «ФИО», «кафедра». Выделение тех или иных сущностей и их атрибутов определяется требованиями, накладываемыми на содержание базы данных, то есть задается теми параметрами, которые необходимо учитывать при проектировании базы данных. Атрибут, однозначно идентифицирующий конкретный экземпляр сущности, называется ключевым. Для сущности «студент» в качестве ключевого атрибута можно обозначить «номер зачетной книжки», поскольку для всех студентов данного вуза номера зачетных книжек будут различны. Для сущности «преподаватель» можно выделить «табельный номер». Между сущностями могут быть установлены связи. Связи - это бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. По множественности связи делятся на три типа: · «один-ко-многим» (1:М) - один экземпляр одной сущности может быть связан с несколькими экземплярами другой сущности; · «один-к-одному» (1:1)- один экземпляр одной сущности связан только с одним экземпляром другой сущности; · «многие-ко-многим»(М:М) - один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности или один экземпляр второй сущности может быть связан несколькими экземплярами первой сущности. Сама по себе ER-модель представляет графическое изображение связанных друг с другом прямоугольников, в верхней части которых записываются имена сущностей, а ниже перечисляются атрибуты[1]. Ключевой атрибут выделяется подчеркиванием и, как правило, располагается на первом месте (рис. 18-20). На рис. 18 приведен пример самого распространенного типа связи «один-ко-многим». С точки зрения руководства дипломным проектированием на каждого преподавателя может приходиться несколько студентов, а у каждого студента может быть только один руководитель дипломного проектирования. Поэтому между сущностями «преподаватель» и «студент» тип связи будет «1:М», что обозначено на рисунке путем разделения линии связи на три.
Сущность, которая находится на стороне «один», будет называться основной, а та, которая на стороне «многие» - подчиненной. В данном примере основной будет сущность «преподаватель», а подчиненной – «студент».
Пример связи «многие-ко-многим» показан на рис. 20. При обучении в вузе каждый студент слушает лекции у нескольких преподавателей. В свою очередь, каждый преподаватель читает лекции многим студентам. Поэтому с точки зрения лекционных занятий связь между сущностями «студент» и «преподаватель» будет «М:М». Связь любого типа может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, и необязательной. Связь может быть обязательной с одной стороны и необязательной с другой. Реляционная модель данных Реляционная модель данных - основная модель в классе теоретико-множественных моделей. Простота, наглядность и серьезное теоретическое обоснование определили большую популярность этой модели. Развитие формального аппарата представления и манипулирования данными в рамках реляционной модели сделали ее наиболее перспективной для использования. В настоящее время большинство баз данных, работающих со структурированной информацией, являются реляционными. Теоретической основой этой модели стала теория отношений и реляционная алгебра. Американский математик Э.Ф.Кодд в 1970 году сформулировал основные понятия реляционной модели. Основной структурой данных в модели является отношение, именно поэтому модель получила название реляционной (от англ. relation - отношение). Отношение представляет собой таблицу. Заголовок таблицы играет ту же роль, что и имя сущности. Столбцы таблицы соответствуют атрибутам сущности и в реляционной модели называются атрибутами (вхождениями доменов), строки – экземплярам сущности и называются кортежами. Например, отношение «студент» представляет собой следующую таблицу.
Количество строк в таблице определяется количеством студентов – кортежей. Реляционная модель представляет базу данных в виде множества взаимосвязанных отношений (таблиц). Между отношениями существуют связи. В каждой связи одно отношение может выступать как основное, а другое отношение выступает в роли подчиненного. Это означает, что один кортеж основного отношения может быть связан с несколькими кортежами подчиненного отношения. Для поддержания связей оба отношения должны содержать наборы атрибутов, по которым они связаны. В основном отношении таким атрибутом является первичный ключ (аналог ключевого атрибута ER модели). В подчиненном отношении для моделирования связи должен присутствовать атрибут, соответствующий первичному ключу основного отношения. Такой атрибут в подчиненном отношении является вторичным ключом и называется внешним ключом. На рис. 21 приведен пример схемы связи «дипломное проектирование» с точки зрения реляционной модели. Основным отношением будет «преподаватель», подчиненным – «студент». Первичным ключом основного отношения – «таб номер» отношения «преподаватель», внешним ключом – «таб номер» отношения «студент» (которое уже не является ключевым!). Этот атрибут отсутствовал в ER модели у сущности «студент». Он нужен для организации связи в реляционной модели, так как в ней, в отличие от ER модели, связь осуществляется не между таблицами целиком, а между конкретными атрибутами отношений. Как правило, эти атрибуты имеют одинаковые названия («таб номер» - «таб номер»).
На рис. 20 была приведена схема связи отношений «Студент» и «Преподаватель». Сами отношения можно представить в следующем виде (рис. 22). Здесь первой записи отношения «Преподаватель» соответствуют первая и вторая записи отношения «Студент» (Летков руководит дипломными проектами у Иванова и Петрова). Второй записи (Сомов А.Н.) таблицы «Преподаватель» соответствуют третья и пятая записи таблицы «Студент», и т.д. То есть по внешнему ключу (по табельному номеру преподавателя) можно определить, кто является руководителем дипломного проекта. Одним из основополагающих понятий в технологии БД является понятие целостности. Под целостностью понимают соответствие информационной модели предметной области, хранимой в БД, объектам реального мира и их взаимодействиям в каждый момент времени. Поддержка целостности включает в себя три аспекта: · структурная целостность – допустимыми являются только данные, представленные в виде отношений реляционной модели; · языковая целостность - допускаются языки манипулирования данными высокого уровня (не ниже стандарта SQL); · ссылочная целостность - обеспечение поддержки непротиворечивого состояния БД в процессе модификации данных при выполнении операций добавления или удаления.
Кроме указанных ограничений целостности, вводится понятие семантической поддержки целостности. Структурная, языковая и ссылочная целостность определяют правила работы СУБД с реляционными структурами данных. Но эти аспекты никак не касаются содержания БД. Принципы семантической поддержки целостности позволяют накладывать ограничения на содержание БД (например, в библиотеке записаны читатели не моложе 16 лет).
Этапы проектирования реляционных баз данных Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели. Можно выделить следующие этапы проектирования. 1. Системный анализ и словесное описание информационных объектов предметной области. 2. Концептуальное проектирование – частично формализованное описание объектов предметной области в терминах некой инфологической, например, ER-модели. 3. Даталогическое или логическое проектирование БД, то есть описание БД в терминах принятой даталогической модели. 4. Физическое проектирование БД, то есть выбор способа размещения БД на внешних носителях и создание файла БД в какой-либо СУБД. Первый этап, системный анализ, должен заканчиваться подробным описанием информации об объектах, формулировкой задач с кратким описанием алгоритмов их решения, описанием входных и выходных документов. Между этапами концептуального и логического проектирования необходимо решить, с помощью какой СУБД будет реализовываться проект. Для ER-модели существуют алгоритмы ее преобразования в иерархическую, сетевую или реляционную модели данных. Так как в настоящее время почти везде используются реляционные БД, остановимся на последнем алгоритме. Алгоритм преобразования ER-модели в реляционную модель данных 1. Каждой сущности ставится в соответствие отношение реляционной модели данных. 2. Каждый атрибут сущности становится атрибутом соответствующего отношения. Для каждого атрибута задается тип данных и обязательность (или необязательность) данного атрибута. 3. Ключевой атрибут сущности становится первичным ключом соответствующего отношения. 4. Если в ER-модели присутствуют связи «один-ко-многим», то в каждое отношение, соответствующее подчиненной сущности, добавляется атрибут основной сущности, и этот атрибут становится внешним ключом. Для определения обязательного (необязательного) типа связи у атрибута, соответствующего внешнему ключу, устанавливается обязательность (необязательность). 5. Если в ER-модели присутствуют связи «один-к-одному», то необходимо учесть, что в реляционной модели такая связь может быть организована только между ключевыми атрибутами отношений, которые должны иметь одинаковые названия. 6. Если в ER-модели присутствуют связи «многие-ко-многим», то для перехода к реляционной модели данных (где такие связи не поддерживаются) вводится дополнительное связующее отношение. Оно связано с каждым исходным отношением связью «один-ко-многим», а его атрибутами являются первичны
|
