Презентация Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД

Смотреть слайды в полном размере
Презентация Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД


Вашему вниманию предлагается презентация «Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД», с которой можно предварительно ознакомиться, просмотреть текст и слайды к ней, а так же, в случае, если она вам подходит - скачать файл для редактирования или печати.

Презентация содержит 59 слайдов и доступна для скачивания в формате ppt. Размер скачиваемого файла: 2.96 MB

Просмотреть и скачать

Pic.1
Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД, слайд 1
Pic.2
Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД, слайд 2
Pic.3
Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД, слайд 3
Pic.4
Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД, слайд 4
Pic.5
Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД, слайд 5
Pic.6
Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД, слайд 6
Pic.7
Примеры МИС. Демо-версия MGERM доступны на сайте Программа обеспечивает хранение медицинских записей
Примеры МИС. Демо-версия MGERM доступны на сайте Программа обеспечивает хранение медицинских записей и авторизированный доступ к ним в соответствии с ГОСТ Р 52636-2006. ГОСТ Р 52636--2006 — первый в области медицинской информатики. Разработан в 2005 году в Гематологическом научном центре РАМН при непосредственном участии и поддержке Технического комитета по стандартизации № 466 “Медицинские технологии” Традиционные статистические методы успешно применяются для анализа данных, хранящихся в базах MGERM (факторный, дисперсионный, дескриптивный, корреляционный, регрессионный, компонентный анализ, анализ временных рядов, анализ выживаемости).
Pic.8
Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД, слайд 8
Pic.9
Электронная медицинская карта Электронная медицинская карта (ЭМК) – совокупность электронных персона
Электронная медицинская карта Электронная медицинская карта (ЭМК) – совокупность электронных персональных медицинских записей (ЭПМЗ), относящихся к одному пациенту, собираемых, хранящихся и используемых в рамках одной медицинской организации. В основе формализации данных, как правило, лежит принцип их стандартизации. Контролирует всю стандартизацию, в том числе и медицинскую, Международный комитет по стандартизации –International Standards (ISO). Данные -- сведения, факты, выраженные в формализованном виде, обеспечивающем возможность их хранения, обработки и передачи на материальном носителе в пространстве и во времени.
Pic.10
Электронная медицинская карта Наиболее сложные проблемы для стандартизации – терминологические пробл
Электронная медицинская карта Наиболее сложные проблемы для стандартизации – терминологические проблемы представления и кодирования информации. Кодирование означает преобразование информации в форму, удобную для передачи по определенному каналу связи. Кодирование - преобразование дискретной информации одним из следующих способов: шифрование, сжатие, защита от шума. Основными программами для сжатия (точнее форматами) данных с потерей являются: для графических данных – . JPG, для видеофильмов – . MPG, для звукозаписи – . MP3. Характерными программами (для сжатия данных без их потери при разархивировании являются: для графических данных – . GIF, . TIF, . PCX, . DjVu, для видеофильмов – . AVI, для любых типов данных – . ARJ, . ZIP,RAR.
Pic.11
Электронная медицинская карта Кодирование графических данных (рентгенограмм и т. д. ) может выполнят
Электронная медицинская карта Кодирование графических данных (рентгенограмм и т. д. ) может выполняться в черно-белом и цветном вариантах. Обычно черно-белые изображения кодируются в 256 уровнях серой шкалы. Цветные изображения кодируются более сложно. Чаще всего применяется принцип декомпозиции цвета на три основных цвета: красный (Red, R), зеленый (Green, G) и синий (Blue, B) RGB – 8-разрядная. Более совершенной является система 24-разрядного кодирования, которая приближается к чувствительности человеческого глаза. Количество оттенков цвета здесь достигает 16,5 млн. Такое изображение называется полноцветным (True Color). Чем большеразрядной является система кодирования, тем больше поглощает она аппаратных и программных ресурсов компьютера.
Pic.12
СТАНДАРТЫ DICOM 3. 0– стандарт обмена медицинскими изображениями. IHE – стандарт интеграции информац
СТАНДАРТЫ DICOM 3. 0– стандарт обмена медицинскими изображениями. IHE – стандарт интеграции информационных систем. HL7 (FAQ, News) – стандарт обмена медицинскими данными. ASCI X12 – стандарт обмена электронными документами. IEEE P1157 («MEDIX») – стандарт обмена медицинскими данными. CDA – стандарт архитектуры клинических документов. ASTM E3. 11 – стандарт обмена данными лабораторных тестов. CCOW – стандарт клинического контекста.
Pic.13
Нормативно-правовые акты НПА, описывающие требования к электронной карте, включают: 1) ФЗ РФ от 28.
Нормативно-правовые акты НПА, описывающие требования к электронной карте, включают: 1) ФЗ РФ от 28. 06. 2014 № 53 “Об электронной подписи”. 2) Постановление Правительства РФ от 28. 01. 2002 № 65 «О федеральной целевой программе “Электронная Россия (2002–2010 годы)”». 3) ГОСТ Р ИСО/ТО 20514-2009 (2005) Электронный учет здоровья. Определение, область применения и контекст. 4) “Электронная история болезни. Общие положения. ГОСТ Р 52636-2006”. 5) "Медицинские информационные системы. ГОСТ 15971-90 «Системы обработки информации. Термины и определения».
Pic.14
Нормативно-правовые акты 6) ГОСТ Р ИСО 21549-4-2008 “Информатизация здоровья. Структура данных на пл
Нормативно-правовые акты 6) ГОСТ Р ИСО 21549-4-2008 “Информатизация здоровья. Структура данных на пластиковой карте пациента. 7) ГОСТ Р ИСО/TС 18308-2008 Требования к архитектуре электронного учета здоровья (Requirements for an Electronic Health Record architecture). И т. д.
Pic.15
Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД, слайд 15
Pic.16
Модели данных. Примеры МИС. Стандарты. Шкалы измерения параметров. Этапы проектирования БД, слайд 16
Pic.17
Типы шкал параметров наблюдений Шкала определяет множество возможных оценок показателя и их допустим
Типы шкал параметров наблюдений Шкала определяет множество возможных оценок показателя и их допустимых преобразований. Каждый тип шкалы имеет свою информативность и свой класс допустимых преобразований (т. е. операций с показателем), за пределы которого нельзя выходить без риска получить ошибочные или бессмысленные результаты. При измерении показателей наибольшее распространение получили номинальные, порядковые и метрические шкалы. Среди метрических выделяют абсолютные шкалы, шкалы отношений и интервальные шкалы.
Pic.18
Номинальная шкала
Номинальная шкала
Pic.19
Порядковая шкала
Порядковая шкала
Pic.20
Интервальная шкала и шкала отношений
Интервальная шкала и шкала отношений
Pic.21
Интервальная шкала и шкала отношений Интервальная и рациональная шкалы относятся к чисто количествен
Интервальная шкала и шкала отношений Интервальная и рациональная шкалы относятся к чисто количественным типам данных. В интервальной шкале мы уже можем определить, насколько одно значение переменной отличается от другого. Так, повышение температуры тела на 1 градус Цельсия всегда означает увеличение выделяемой теплоты на фиксированное количество единиц. Однако в интервальной шкале есть и положительные и отрицательные величины (нет абсолютного нуля). В связи с этим невозможно сказать, что 20 градусов Цельсия - это в два раза теплее, чем 10. Мы можем лишь констатировать, что 20 градусов настолько же теплее 10, как 30 - теплее 20. Рациональная шкала (шкала отношений) имеет одну точку отсчета и только положительные значения. В медицине большинство рациональных шкал - это концентрации. Например, уровень глюкозы 10 ммоль/л - это в два раза большая концентрация по сравнению с 5 ммоль/л. Для температуры рациональной шкалой является шкала Кельвина, где есть абсолютный ноль (отсутствие тепла).
Pic.22
Интервальная шкала и шкала отношений
Интервальная шкала и шкала отношений
Pic.23
Проблемы информатизации здравоохранения онтологическая сложность медицинской деятельности. Онтология
Проблемы информатизации здравоохранения онтологическая сложность медицинской деятельности. Онтология – это формальная спецификация концептуализации, которая имеет место в некотором контексте предметной области более 33 тыс. нозологических форм заболеваний (МКБ-10). около 5 тысяч наименований медицинских услуг (НМУ) более 70 тысяч наименований медицинских изделий (ГРМИ). около 9 тысяч МНН лекарственных средств многообразие моделей представления медицинских данных, систем классификации и кодирования информации . динамичность изменения требований к ИС .
Pic.24
Направления информатизации здравоохранения компьютеризированные медицинские и лабораторные приборы и
Направления информатизации здравоохранения компьютеризированные медицинские и лабораторные приборы и комплексы, интегрированные цифровые диагностические кабинеты и операционные фасовочные машины лекарственных препаратов компьютеризированные хирургические роботы (Da Vinchi) автоматические транспортные роботы-контейнеры автоматизация исследований -> аналитическая обработка массивов данных (OLAP, Data Mining, Big Data) компьютерное моделирование, анимация, распознавание образов и визуальная идентификация компьютеризированные медицинские тренажеры, симуляционные центры компьютерные методы визуализации, когнитивная графика 3D-моделирование + 3D-сканеры + 3D-принтеры + биопринтеры
Pic.25
специфичные для медицинских организаций( МО) функции Планирование работы врачей, кабинетов, операцио
специфичные для медицинских организаций( МО) функции Планирование работы врачей, кабинетов, операционных, лабораторий и т. д. Электронная регистратура (ЭР) Электронная медицинская карта Вакцинация (иммунизация) Реанимация Клиническая лаборатория Радиологическая ИС Аптека и расходные материалы Регистр(ы) пациентов Взаиморасчеты за медицинскую помощь Сбор данных для статистики
Pic.26
ПОДХОДЫ В ПРОЕКТИРОВАНИИ БД 1. Классический подход к проектированию. Подход исходит от системы докум
ПОДХОДЫ В ПРОЕКТИРОВАНИИ БД 1. Классический подход к проектированию. Подход исходит от системы документов -на входе БД имелась одна система документов, которая при использовании БД трансформировалась в другую (выходную) систему документов (таблиц, файлов). 2. Современный подход к проектированию. Современный подход исходит от задач (в терминах АСУ), т. е. от приложений, под которые создается БД. Под приложением понимается программа или группа программ, предназначенных для выполнения определенных однотипных работ.
Pic.27
ЭТАПЫ ПРИ ПРОЕКТИРОВАНИИ БД КОНЦЕПТУАЛЬНОЕ МОДЕЛИРОВАНИЕ (инфологическое) ЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ (
ЭТАПЫ ПРИ ПРОЕКТИРОВАНИИ БД КОНЦЕПТУАЛЬНОЕ МОДЕЛИРОВАНИЕ (инфологическое) ЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ (даталогическое) ФИЗИЧЕСКОЕ МОДЕЛИРОВАНИЕ
Pic.28
КОНЦЕПТУАЛЬНОЕ (инфологическое) ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ 1. Создание локальной концептуальной моде
КОНЦЕПТУАЛЬНОЕ (инфологическое) ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ 1. Создание локальной концептуальной модели данных исходя из представлений о предметной области каждого из типов пользователей. 2. Определение типов сущностей. 3. Определение типов связей. 4. Определение атрибутов, связывание их с типами сущностей, определение связей. 5. Определение доменов атрибутов. 6. Определение атрибутов, являющихся потенциальными и первичными ключами. 7. Проверка модели на отсутствие избыточности. 8. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям, обсуждение концептуальных моделей данных с конечными пользователями.
Pic.29
ПРЕДМЕТНАЯ ОБЛАСТЬ Предметной областью называется часть реального мира, представляющая интерес для и
ПРЕДМЕТНАЯ ОБЛАСТЬ Предметной областью называется часть реального мира, представляющая интерес для исследования (использования). Описание предметной области содержит: цель, назначение, основные функции предприятия или организации, пользователи; описание входных и выходных документов, используемых при выполнении функций; описание всех используемых и создаваемых элементов данных; определение задач и запросов пользователей и их характеристик; направление развития.
Pic.30
ТЕХНИЧЕСКОЕ ЗАДАНИЕ-ТЗ В ТЗ должны быть определены основные цели приложения БД, технические требован
ТЕХНИЧЕСКОЕ ЗАДАНИЕ-ТЗ В ТЗ должны быть определены основные цели приложения БД, технические требования (ТТ). ТТ должны содержать перечень конкретных задач, реализуемых с использованием БД. В разработке ТЗ участвуют инициаторы разработки проекта БД ( директор или владелец предприятия).
Pic.31
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ •"Каковы задачи вашей организации, учреждения?" • "Для чего, п
ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ •"Каковы задачи вашей организации, учреждения?" • "Для чего, по вашему мнению, необходимо создать базу данных?" • "Почему вы думаете, что база данных поможет решить ваши проблемы?« "Каковы ваши должностные обязанности?" •"Какого вида задачи вы повседневно выполняете?" •"С данными какого рода вы обычно работаете?" •"Какого типа отчеты вы обычно используете?" •"Дела какого типа вам необходимо отслеживать?" •"Какие услуги предоставляет ваша организация своим клиентам ?"
Pic.32
МЕТОДИКИ СБОРА ФАКТОВ О ПРЕДМЕТНОЙ ОБЛАСТИ Изучение документации; Проведение собеседований; Наблюден
МЕТОДИКИ СБОРА ФАКТОВ О ПРЕДМЕТНОЙ ОБЛАСТИ Изучение документации; Проведение собеседований; Наблюдение за работой организации; Проведение исследований; Проведение анкетирования.
Pic.33
ИЗУЧЕНИЕ ДОКУМЕНТАЦИИ
ИЗУЧЕНИЕ ДОКУМЕНТАЦИИ
Pic.34
СОБЕСЕДОВАНИЕ
СОБЕСЕДОВАНИЕ
Pic.35
НАБЛЮДЕНИЕ
НАБЛЮДЕНИЕ
Pic.36
ИССЛЕДОВАНИЕ
ИССЛЕДОВАНИЕ
Pic.37
АНКЕТИРОВАНИЕ
АНКЕТИРОВАНИЕ
Pic.38
СБОР ИНФОРМАЦИИ О ПОЛЬЗОВАТЕЛЬСКИХ ПРЕДСТАВЛЕНИЯХ
СБОР ИНФОРМАЦИИ О ПОЛЬЗОВАТЕЛЬСКИХ ПРЕДСТАВЛЕНИЯХ
Pic.39
СБОР ИНФОРМАЦИИ О СИСТЕМНЫХ ТРЕБОВАНИЯХ ДЛЯ ПРИЛОЖЕНИЯ БД
СБОР ИНФОРМАЦИИ О СИСТЕМНЫХ ТРЕБОВАНИЯХ ДЛЯ ПРИЛОЖЕНИЯ БД
Pic.40
СИСТЕМНАЯ СПЕЦИФИКАЦИЯ ДЛЯ ПРИЛОЖЕНИЯ БД начальный размер базы данных; темп роста базы данных; типы
СИСТЕМНАЯ СПЕЦИФИКАЦИЯ ДЛЯ ПРИЛОЖЕНИЯ БД начальный размер базы данных; темп роста базы данных; типы информационного поиска и их распределение по частоте использования; требования к работе в сети и совместному доступу; производительность; защита; резервное копирование и восстановление; юридические вопросы.
Pic.41
СИСТЕМНАЯ СПЕЦИФИКАЦИЯ Защита 1. База данных должна быть защищена паролем. 2. Каждому сотруднику дол
СИСТЕМНАЯ СПЕЦИФИКАЦИЯ Защита 1. База данных должна быть защищена паролем. 2. Каждому сотруднику должны быть присвоены привилегии (полномочия) доступа к базе данных согласно его пользовательскому представлению, а именно: главного врача, врача, старшей сестры и регистратора. 3. Сотруднику можно видеть только данные, необходимые для его работы, и в удобном для этого виде. Копирование и восстановление База данных должна копироваться ежедневно в полночь. Юридические вопросы 1. В каждой стране имеются законы, регулирующие способ компьютеризированного хранения личных данных. 2. Так, если база данных содержит данные о персонале, пациентах необходимо изучить и учитывать любые правовые нормы, которым она должна удовлетворять.
Pic.42
ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Логическая модель данных учитывает особенности выбранной модели организаци
ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ Логическая модель данных учитывает особенности выбранной модели организации данных в целевой СУБД (например, реляционная). На этом этапе игнорируются остальные характеристики выбранной СУБД, например, любые особенности физической организации ее структур хранения данных и построения индексов. Для проверки правильности логической модели данных используется метод нормализации.
Pic.43
ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД Проектирование базовых отношений в среде целевой СУБД, отношений, содер
ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД Проектирование базовых отношений в среде целевой СУБД, отношений, содержащих производные данные. Реализация ограничений предметной области. Проектирование физического представления БД Анализ транзакций. Выбор файловой структуры. Определение индексов.
Pic.44
ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД Определение требований к дисковой памяти. Разработка пользовательских п
ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД Определение требований к дисковой памяти. Разработка пользовательских представлений. Анализ необходимости введения контролируемой избыточности. Организация мониторинга и настройка функционирования ОС. Разработка средств и механизмов защиты. Выбор типа носителя, методов доступа (определение пользователей базы данных, их уровней доступа, разработка и внедрение правил безопасности доступа), Определение размеров физического блока, управление размещением данных на внешнем носителе, Управление свободной памятью, определение целесообразности сжатия данных и используемых методов сжатия,
Pic.45
ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД оценка размеров объектов базы (определение размеров табличных пространс
ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БД оценка размеров объектов базы (определение размеров табличных пространств и особенностей их размещения на носителях информации, определение спецификации носителей информации для промышленной системы (например, тип raid-массивов, их количество), разработка топологии базы данных в случае распределенной базы данных, определение механизмов доступа к удаленным данным.
Pic.46
Модели данных
Модели данных
Pic.47
Модели данных 1. Иерархический подход к организации баз данных Иерархическая модель - первая модель
Модели данных 1. Иерархический подход к организации баз данных Иерархическая модель - первая модель хранения данных в вычислительной технике. Эту модель поддерживала первая из зарегистрированных промышленных СУБД IMS фирмы IBM. Иерархические базы данных имеют форму деревьев с дугами-связями и узлами-элементами данных.
Pic.48
Модели данных
Модели данных
Pic.49
Модели данных
Модели данных
Pic.50
Модели данных 1. Иерархический подход к организации баз данных эффективность в использовании памяти
Модели данных 1. Иерархический подход к организации баз данных эффективность в использовании памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. удобна для работы с иерархически упорядоченной информацией; автоматически поддерживается целостность ссылок между предками и потомками; невозможность реализовать отношения "многие-ко-многим "; большое дублирование данных; усложняются операции включения и удаления; быстрота доступа в иерархической модели достигнута за счет потери информационной гибкости.
Pic.51
Модели данных 2. Сетевая модель данных наряду с вертикальными реализованы и горизонтальные связи; бо
Модели данных 2. Сетевая модель данных наряду с вертикальными реализованы и горизонтальные связи; более богатая структура запросов по сравнению с иерархической моделью, возможность эффективной реализации по показателям затрат памяти и оперативности; необходимость четко определять на физическом уровне связи данных и четко следовать этой структуре связей при запросах к базе; ослаблен контроль целостности связей вследствие допустимости установления производственных связей между записями.
Pic.52
Модели данных 3. Реляционная модель предложена сотрудником лаборатории IBM Эдгаром Коддом в 1970 год
Модели данных 3. Реляционная модель предложена сотрудником лаборатории IBM Эдгаром Коддом в 1970 году; основным понятием модели является отношение или связь (relation).
Pic.53
Модели данных Отношение представляет собой двумерную таблицу, содержащую некоторые данные. Сущность
Модели данных Отношение представляет собой двумерную таблицу, содержащую некоторые данные. Сущность - объект любой природы, данные о котором хрянятся в БД. Данные о сущности находятся в отношениях. Атрибуты представляют собой свойства, которые характеризуют сущность. В структуре таблицы каждый атрибут именуется, и ему соответствует заголовок некоторого столбца таблицы. Домен представляет собой множество всех возможных значений определенного атрибута.
Pic.54
Модели данных 3. Требования к реляционная модели: Представление БД в виде совокупности упорядоченных
Модели данных 3. Требования к реляционная модели: Представление БД в виде совокупности упорядоченных нормализованных отношений. Любой тип записи содержит только простые (по структуре) элементы данных. Порядок кортежей в таблице несуществен. Упорядочение значащих атрибутов в кортеже должно соответствовать упорядочению атрибутов в реляционном отношении. Нет одинаковых кортежей.
Pic.55
Модели данных 3. Реляционная модель Любое отношение должно содержать один атрибут или более, которые
Модели данных 3. Реляционная модель Любое отношение должно содержать один атрибут или более, которые вместе составляют уникальный первичный ключ. Если между двумя реляционными отношениями существует зависимость, то одно отношение является исходным, второе - подчиненным. Чтобы между двумя реляционными отношениями существовала зависимость, атрибуты, служащие первичным ключом в исходном отношении, должны также присутствовать в подчиненном отношении.
Pic.56
Модели данных 3. Реляционная модель простота логической модели; гибкость системы защиты (для каждого
Модели данных 3. Реляционная модель простота логической модели; гибкость системы защиты (для каждого отношения может быть задана правомерность доступа); независимость данных; возможность построения простого языка манипулирования данными с помощью математически строгой теории реляционной алгебры (алгебры отношений); сложность описания иерархических и сетевых связей, необходимость нормализации данных.
Pic.57
Модели данных 4. Постреляционная модель Допускает многозначные поля ( набор значений многозначных по
Модели данных 4. Постреляционная модель Допускает многозначные поля ( набор значений многозначных полей считается самостоятельной таблицей, встроенной в основную). Поддерживает также многоуровневые ассоциированные поля. Совокупность ассоциированных полей - ассоциация. (первое значение одного столбца ассоциации соответствует первым значениям всех остальных столбцов ассоциации). На длину полей и количество полей в записях не накладывается ограничение постоянства.
Pic.58
Модели данных 5. Объектно-ориентированная модель Структура объектно-ориентированной БД графически пр
Модели данных 5. Объектно-ориентированная модель Структура объектно-ориентированной БД графически представима в виде дерева, узлами которого являются объекты. Хранение и обработка разных объектов - текст, аудио- и видеоинформацию, а также документы. Для выполнения действий над данными применяются логические операции, усиленные объектно-ориентированными механизмами.
Pic.59
Модели данных 5. Объектно-ориентированная модель неограниченный набор типов данных, послойное предст
Модели данных 5. Объектно-ориентированная модель неограниченный набор типов данных, послойное представление информации; отсутствие нормализации, высокая скорость работы из-за отсутствия ключей; легкая расширяемость структуры и её гибкость; реализация отношения многие к многим; недостаточная защита данных, одновременный доступ отсутствуют мощные непроцедурные средства извлечения объектов из базы, обеспечения ограничений целостности данных). отсутствует развитый математический аппарат для объектно-ориентированной модели данных.


Скачать презентацию

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