Google, DocVerse'i satın aldı. Cloud Computing'in en yaygın örneklerinden biri olan Google Docs artık DocVerse'in sağladığı paylaşım özellikleri ile daha da güçleneceğe benziyor.
Artık sadece online dosyalarımızı değil, bilgisayarımızdaki dosyalarımızı ve klasörlerimizi de google docs'a yükleyip, cloud computing nimetlerinden faydalanabileceğiz.
Google Docs'daki dökümanlarımızı desktop'da rahatça kullanabilmemiz için de memeo isimli bir uygulama yazmış google.
Google Docs'u aktif olarak kullanmaya başlayınca senkronizasyon ve yedekleme ihtiyaçlarımız da doğacak tabii ki. Bunun için de syncplicity uygulaması imdadımıza yetişiyor.
Google, gelecek Cloud'da diyor ve bununla ilgili yatırımlarına devam edecek gibi görünüyor. Bakalım, gelecekte neler olacak?
Google'ın DocVerse'i almasıyle ilgili haberi google'ın blog'ından okuyabilirsiniz : http://googleenterprise.blogspot.com/2010/03/google-docs-welcomes-docverse.html
1 Nisan 2010 Perşembe
29 Mart 2010 Pazartesi
Kimball'dan Veri Ambarı Geliştirme Önerileri
Ralph Kimball, The Data Warehouse Toolkit isimli kitabında, yeni bir veri ambarı geliştirirken dikkat edilmesi gereken tuzaklardan bahsetmiş.
İşte Kimball'ın önerileri :
İşte Kimball'ın önerileri :
- İş gereksinimleri ve amaçlarına odaklanmak yerine teknoloji ve dataya takılmayın.
- Veri ambarı işini destekleyenlerin makul bir yönetim vizyonuna sahip olmaması veya işi yeterince sahiplenmemesi sorun olabilir.
- Kolay yönetilebilir, ilgi çekici devam edecek proje yerine, çok büyük, yıllar sürecek ve çaba gerektiren projeler ile mücadele etmeyin.
- Dimensional modellere dayanan kullanışlı bir görsellik yaratmadan, normalize edilmiş veri yapılarına enerji harcamayın.
- Arka plandaki operasyonel performans ve geliştirme kolaylığından fazla, ön yüzün kullanım kolaylığı ve performansına önem vermeyin.
- Belki sorgulanabilir diye, görsel katmanı fazla karmaşık yapmayın. Veritabanı tasarımcıları, karmaşık sorgular yerine, kullanıcıların basit ihtiyaçlarını karşılarlar ise daha fazla takdir edilirler.
- Ortak, birbirine bağlanabilen dimension tablolarından oluşan veri mimarisi yerine tek başına kullanılabilecek dimension tablolarından oluşan yapılar kurun.
- Görsel alandaki dimension yapılarına sadece özet data yükleyin.
- Bir işin gereksinimlerinin, altındaki verinin ve işin yapıldığı teknolojinin statik olduğunu varsayın.
- Veri ambarının başarısının kullanıcının işi benimsemesiyle ilgili olduğunu unutmayın. Kullanıcı, veri ambarını karar vermenin temeli olarak kabul etmezse tüm çabalarınız boşa gider.
Inmon ve Kimball'ın Data Warehouse Modellemeleri
Mary Breslin, data warehouse modellemenin iki babası Kimball ve Inmon un modellerini karsilastırdığı bir makale yazmış. İşte makalenin kısa bir özeti
Inmon'un yaklaşımı, klasik ilişkisel veritabanı araçları ve yöntemleri kullanılarak yapılan "top-down development" üzerine kurulu.
Inmon, data warehouse'u daha büyük bir bilgi ortamının bir parçası olarak görüyor. Bu büyük bilgi ortamına da CIF (Corporate ınformation Factory) adını veriyor. Data warehouse'un daha büyük ortamlara iyi uyum sağlaması için, bir atomik bir de birimlere özel veri tabanı olması gerektiğini savunuyor.
Inmon'ın yöntemleri sadece IT uzmanları tarafından aktif olarak kullanılabilir durumda. Son kullanıcılar geliştirme aşamasında aktif rol oynamıyor. Kısacası Inmon'un yaklaşımı daha teknik bir yaklaşım.
Operasyonel (Transactional) sistemlerde işlenen veri, gerekli şekillerde düzenlenerek (Bu işleme ETL deniyor) atomik veritabanına taşınıyor. Her bir departman için, ihtiyaca göre ayrı bir veritabanı tasarlanıyor ve bu veritabanları temel verileri atomik veritabanından alıyor. Böylece departmanların aldıkları raporlar arasında veri uyumsuzluğu sorunu olmuyor.
Kimball'in yaklaşımı ise geleneksel veritabanı tasarım metodlarından farklı. "Bottom - up" yaklaşımı ile her iş süreci için ayrı bir data mart oluşturmayı tavsiye ediyor. Tüm bu data mart ların toplamı ise kuruluşun data warehouse U oluyor. Çeşitli data mart'lar arasında iletişim kurmak için de "data bus" dediği ve tüm data Mart'ların standarta uygun veri boyutları ile modellenmesini gerektiren bir mimari öneriyor.
Verinin son kullanici tarafindan daha rahat anlasilmasi ve performans nedeniyle Normalizasyon kurallarının gecerli olmadigi Dimensional veri modeli tasarimlarda çok merkezi rol oynuyor. Dimensional modelde iki çeşit tablo oluyor. Fact tablolar, çok fazla satırdan olusan ancak buna karşılık az kolon içeren foerign key ve metrik ölçüm dısında bir veri tutmayan tablolara deniyor. Dimension tablolar ise fact tablolardaki verinin detaylarını ve ozelliklerini tutan tablolar ve fact e göre daha az satır içermelerine rağmen yüzlerce kolondan oluşabiliyorlar.
Inmon ve Kimball' in modellerinin benzer noktaları da var.Her ikisi de farklı yöntemlerle de olsa zaman özelliği tutmak gerektiğini savunuyor. Her iki model de verilerin transactional sistemden aktarılırken standartlastirilmasi ve düzenlenmesini oneriyor (ETL)
Hangi modelin kullanılacağı tamamen ihtiyaclara ve isin yapısına göre verilecek bir karar.
Makeleyi okumak için : http://www.bi-bestpractices.com/view-articles/4768
Inmon'un yaklaşımı, klasik ilişkisel veritabanı araçları ve yöntemleri kullanılarak yapılan "top-down development" üzerine kurulu.
Inmon, data warehouse'u daha büyük bir bilgi ortamının bir parçası olarak görüyor. Bu büyük bilgi ortamına da CIF (Corporate ınformation Factory) adını veriyor. Data warehouse'un daha büyük ortamlara iyi uyum sağlaması için, bir atomik bir de birimlere özel veri tabanı olması gerektiğini savunuyor.
Inmon'ın yöntemleri sadece IT uzmanları tarafından aktif olarak kullanılabilir durumda. Son kullanıcılar geliştirme aşamasında aktif rol oynamıyor. Kısacası Inmon'un yaklaşımı daha teknik bir yaklaşım.
Operasyonel (Transactional) sistemlerde işlenen veri, gerekli şekillerde düzenlenerek (Bu işleme ETL deniyor) atomik veritabanına taşınıyor. Her bir departman için, ihtiyaca göre ayrı bir veritabanı tasarlanıyor ve bu veritabanları temel verileri atomik veritabanından alıyor. Böylece departmanların aldıkları raporlar arasında veri uyumsuzluğu sorunu olmuyor.
Kimball'in yaklaşımı ise geleneksel veritabanı tasarım metodlarından farklı. "Bottom - up" yaklaşımı ile her iş süreci için ayrı bir data mart oluşturmayı tavsiye ediyor. Tüm bu data mart ların toplamı ise kuruluşun data warehouse U oluyor. Çeşitli data mart'lar arasında iletişim kurmak için de "data bus" dediği ve tüm data Mart'ların standarta uygun veri boyutları ile modellenmesini gerektiren bir mimari öneriyor.
Verinin son kullanici tarafindan daha rahat anlasilmasi ve performans nedeniyle Normalizasyon kurallarının gecerli olmadigi Dimensional veri modeli tasarimlarda çok merkezi rol oynuyor. Dimensional modelde iki çeşit tablo oluyor. Fact tablolar, çok fazla satırdan olusan ancak buna karşılık az kolon içeren foerign key ve metrik ölçüm dısında bir veri tutmayan tablolara deniyor. Dimension tablolar ise fact tablolardaki verinin detaylarını ve ozelliklerini tutan tablolar ve fact e göre daha az satır içermelerine rağmen yüzlerce kolondan oluşabiliyorlar.
Inmon ve Kimball' in modellerinin benzer noktaları da var.Her ikisi de farklı yöntemlerle de olsa zaman özelliği tutmak gerektiğini savunuyor. Her iki model de verilerin transactional sistemden aktarılırken standartlastirilmasi ve düzenlenmesini oneriyor (ETL)
Hangi modelin kullanılacağı tamamen ihtiyaclara ve isin yapısına göre verilecek bir karar.
Makeleyi okumak için : http://www.bi-bestpractices.com/view-articles/4768
10 Şubat 2010 Çarşamba
Business 2.0 : Digital Age Business
Presentation of Yüce Zerey
Business 2.0 Course Information
View more presentations from Yuce Zerey.
29 Ocak 2010 Cuma
23 Ocak 2009 Cuma
Boyutu değişen pencerenin boyutunu öğrenme(Firefox ve IE de çalışır)
İşte ie ve firefox da çalışan, pencerenin boyutunun değiştiğinden haberdar olan bir javascript örneği.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> //Browser'ın boyutu her değiştiğinde windowResized fonksiyonu çalışacak window.onresize = windowResized; //Do it on every window resize- // Ayrı ayrı almaya ihtiyacınız vars aşağıdaki fonksiyonları da kullanabilirsiniz function getWindowHeight(){ return myHeight; function getWindowWidth(){ return myWidth; </head> <body> Yeni boyutları görmek için browser penceresinin boyutunu değiştiriniz. </body> </html> |
24 Eylül 2008 Çarşamba
SQL Server daki tablolalarım disk üzerinde ne kadar yer kaplıyor
Bugün, database'imizde bulunan tüm tabloların datalarının ve indexlerinin ne kadar yer tuttuğunu gösteren bir stored procedure yazacağız. Aşağıdaki kod ile sistemdeki tüm tabloların bilgilerini görebiliriz.
SELECT * FROM sys.tables
sp_MStablespace @TableName sistem prosedürü SQL Server 2000'de de vardı. SQL Server 2005'de de çalışıyor. Çalıştırıldığında tek satırlık 3 kolonluk bir resultset dönüyor.
- Rows: Tabloda kaç satır var
- DataSpaceUsed : Tablodaki veriler ne kadar yer kaplıyor
- IndexSpaceUsed :Tablonun index leri ne kadar yer kaplıyor
CREATE TABLE Test(ID int identity(1,1),TextVal varchar(200))
GO
DECLARE @i int
SET @i=1
WHILE @i<=100 BEGIN
-- Rastgele birşeyle oluşturalım
INSERT INTO Test(TextVal)
SELECT Replicate('ab',@i)
SET @i = @i+ 1
END
SELECT * FROM Test
| ID | TextVal |
| 1 | ab |
| 2 | abab |
| 3 | ababab |
| 4 | abababab |
| 5 | ababababab |
| 6 | abababababab |
| 7 | ababababababab |
| 8 | abababababababab |
| 9 | ababababababababab |
| ... | .... |
100. satırda, 100 kere 'ab' içeren bir datamız olacak.
Yarattığımız tabla ne kadar yer kaplıyormuş bakalım:
exec sp_MStablespace 'Test'
| Rows | DataSpaceUsed | IndexSpaceUsed |
| 100 | 16 | 8 |
Bütün tabloların boyutlarını öğrenmek istersek sys.tables view sistem view ini kullanarak tüm tabolar için bunu çalıştırabiliriz
CREATE TABLE #TableSize(TableName nvarchar(255),Rows int,DataSpace int, IndexSpace int)
DECLARE @Table nvarchar(255)
DECLARE oCur CURSOR READ_ONLY FAST_FORWARD FOR
SELECT name
FROM sys.tables
ORDER BY name
OPEN oCur
WHILE (1=1) BEGIN
FETCH NEXT FROM oCur INTO @Table
IF @@FETCH_STATUS <> 0 BREAK
INSERT INTO #TableSize(Rows,DataSpace,IndexSpace)
EXEC SP_MSTABLESPACE @table
-- Hangi tablo olduğu bilgisi proc. den dönmüyor. Null olarak yazdık. Şimdi güncelleyelim
UPDATE #TableSize SET TableName = @Table WHERE TableName is null
END
CLOSE oCur
DEALLOCATE oCur
SELECT * FROM #TableSize
Şimdi bunu başka bir yöntem ile yapalım.
Tablonun boyutunu öğrenmek için kullanılabilecek bir sistem prosedürü daha var : sp_spaceused @TableName
Bu procedure biraz daha farklı bir sonuç döndürüyor ancak dönen resultset içerisinde tablo nun ismi de var.
exec sp_spaceused 'Test' sonucu:
| name | rows | reserved | data | index_size | unused |
Test | 100 | 24 KB | 16 KB | 8 KB | 0 KB |
Buradan dönen değerleri yine bir tabloya yazalım ama bu sefer cursor yerine farklı bir yöntem kullanalım.
Daha çok tüm tabloların indexlerini yeniden yaratmak için kullandığım bir sistem prosedürü var.
EXEC sp_MSforeachtable @command1='Command String'
@command1 e verilen sql ifadesini çalıştırır. Tablo parametresi geçmek için command içerisinde tablo adı yerine ? geçilir
CREATE TABLE #TableSize
(
[name] nvarchar(255),
[rows] int,
[reserved] varchar(20),
[data] varchar(20),
[index_size] varchar(20),
[unused] varchar(20)
)
-- Mevcut database deki tüm tablolar için sp_spaceused proc. ü çağırılıp, dönen recordset #TableSize tablosu eklenir
EXEC sp_MSforeachtable @command1=
"INSERT INTO #TableSize
EXEC sp_spaceused '?'"
SELECT * FROM #TableSize